SlideShare a Scribd company logo
1 of 148
Download to read offline
Implementing Agile Iterative
Project Delivery Approach
and Achieving Business
Responsiveness


Alan McSweeney
Objectives

•   To describe a generalised agile and iterative approach to
    information technology projects and the use of the agile
    approach within organisations




    August 16, 2010                                             2
Agenda

•   Introduction
•   Agile Iterative Approach to Projects
      − Using Agile Effectively and Productively
      − Control Components of Agile Process
      − Agile Tools and Techniques
      − Iterative Agile Framework and Phases
•   Using Agile Iterative Approach for Specific Projects
•   Introducing Agile Iterative Approach into an Organisation



    August 16, 2010                                             3
Introduction




 August 16, 2010   4
Projects

•   Projects are about change
      − New or changes to existing processes, systems, applications, structures
•   Organisations need to be good at two sets of skills
      − Running the Business (RTB) – business as usual operations
      − Change the Business (CTB) – changing existing operations to survive or compete
•   Projects are the way of introducing change into organisations
•   Projects tend to be multidisciplinary, involving some or all of:
      −    Requirements gathering
      −    Solution design
      −    Hardware installation
      −    Product selection
      −    Software development or modification
      −    Testing
      −    Process change
      −    Organisation change
      −    Data conversion
      −    Implementation
      −    Parallel operation
•   Organisations need to be good at projects in order to deliver change


    August 16, 2010                                                                      5
Dimensions of Being Good At Organisational Change
                                                          Ability to
•   To be good at change, three                        Execute Projects
    dimensions must come
    together within the
    organisation:
      − A clear vision for the
        organisation and the set of
        projects needed to deliver on
        the vision
      − A proven capability to deliver
        projects quickly and
        effectively                                                       Completeness of
                                                                           Organisational
      − Focus on the realisation of                                            Vision
        expected business benefits
        and business value associated
        with the implementation of
        information technology
        investments
•   Agile approach to projects is
    one way of being good at             Effective and Proven
    change                               Benefits Realisation
                                               Approach
    August 16, 2010                                                                     6
Projects Fail

•   Yes – projects fail – it’s no surprise
•   Fail occurs largely because of people rather than technology issues
•   Project success means the project delivered on time, on budget, to agreed
    specification and delivering the agreed business benefits
•   Different types and scales of project failure
      − Delivered solution fails to meet the business requirements for which it was
        implemented and its use is abandoned or expensive adjustments are made
      − There are performance problems in the delivered solution which means it is insufficient
        to meet the needs of users and its use is abandoned or expensive adjustments are
        made
      − After implementation errors and gaps appear in the delivered solution causing
        unexpected problem and its use is abandoned or expensive adjustments are made
      − Users reject, bypass or circumvent the delivered solution because of lack of
        consultation, involvement, commitment, agreement or other reasons
      − Delivered solution is used but over gradually become to expensive or complex to
        maintain and falls into disuse
      − Project is late and/or over budget
      − Project does not deliver the business benefits

    August 16, 2010                                                                               7
Spectrum of Project Failures
More Expensive                                                      Functionality Delivered
to Operate Than                                                     Does not Meet Business
    Planned                                                             Requirements
                                   Specified
                               Business Benefits
                               and Savings Not
Project Late                      Delivered                                      Significant
and/or Over                                                                        Rework
  Budget                                                                          Required



        Complete                                                                 Complete
         Success                                                                  Failure



                    Performance and/or
                        Operational                   Solution
                         Problems                  Largely Unused


                          Complete Project               Complete Project
                              Success:                   Failure: Cancelled,
                         On-time, On-budget              Unused, Rejected
  August 16, 2010                                                                              8
Balancing Solution Functionality and
Implementation Project Cost/Resources and Time
                              •   Traditional view of
                                  projects is that they are
                                  a balance between
                                  meeting requirements
                                  (solution functionality),
                                  implementation project
                                  resources (and thus
                                  cost) and project time
                              •   Functionality
                                  (requirements) is fixed
                                  and cost and time must
                                  vary



 August 16, 2010                                              9
Balancing Solution Functionality and
Implementation Project Cost/Resources and




•   Resources are constrained so   •   Time is constrained so
    project time must increase         resources must increase




    August 16, 2010                                              10
Project Risk/Quality Factor

                              •   Reality is that all
                                  projects have a risk
                                  dimension – projects
                                  fail all too frequently
                              •   Risk and quality are
                                  interrelated
                              •   Risk increases with
                                  project duration, size of
                                  project team and
                                  complexity of solution
                                  being implemented



 August 16, 2010                                              11
Projects and Changes

•   Organisations need to deliver projects to business in shorter timescales in
    response to internal and external
•   Project processes need to be flexible, responsive and agile in order to deliver what
    the organisation needs when it needs it
•   Traditionally projects are delivered in a series of sequential phases designed to
    create certainty around the solution being delivered
      −    Gather requirements
      −    Design solution
      −    Technical and detailed design
      −    Development/modification
      −    Testing
      −    Implementation
      −    Operation
•   Sequential approach has disadvantages
      −    Not sufficiently flexible to accommodate changes in requirements
      −    Resources are wasted building features that nobody needs
      −    Opportunity to provide feedback limited until a large part of the solution is delivered
      −    Solution stability and operability not certain until late in the project


    August 16, 2010                                                                                  12
What Makes Projects Succeed

•   User involvement and commitment
•   Executive management sponsorship
•   Defined and certain business objectives
•   Defined and agreed requirements
•   Defined scope
•   Flexible and reactive delivery process
•   Project management skill and experience
•   Good control of project costs
•   Skilled and experienced project team
•   Project delivery methodology
•   Proven technology

    August 16, 2010                           13
What Makes Projects Fail

•   Lack of or changing executive          •   Unclear definition of roles and
    management commitment                      responsibilities
•   Unclear of scope, objectives and       •   Artificial and unrealistic deadlines
    requirements                           •   Specifications not agreed
•   Lack of user commitment and            •   New or radically redesigned
    involvement                                underlying business processes
•   Changing scope and objectives and      •   Use of new technology
    poor change control
•   Poor planning and estimation           •   Poor project control against targets
•   Poor project management                •   Large number of organisational units
                                               involved
•   Failure to manage end-user             •   Lack of effective project
    expectations                               methodologies
•   Lack of agreement between              •   High project staff turnover
    stakeholders
•   Lack of skills and experience in the
    project team
    August 16, 2010                                                                   14
Flexible, Responsive, Agile Project Approach

•   An agile approach to project delivery seeks to reduce risks
    associated with sequential solution delivery approach
      − Multiple iterations/releases
      − Sets of smaller deliveries
      − Prioritised requirements
      − Greater user involvement
      − Lower overall cost
•   Agile approach tends to be good for projects with inherent
    uncertainty and volatility
      − Transformation and organisational change projects
      − Support and maintenance
      − Research and development
      − Information technology
    August 16, 2010                                               15
Applying Agile Approach to Projects

•   Agile approach tends to be associated with software
    development projects
•   More general approach and can and should be applied
    more widely to other projects (that may have a
    development component)




    August 16, 2010                                       16
Classification of Projects
                      Highly                                                                          Here be
                    Undefined                                                                         Dragons
                   and Far from
                    Agreement



                                  Project Requirements                                       Highly
                                                                                            Complex


                                                                              Complicated


                                                                  Difficult


                       Well
                     Defined/                            Simple
                      Agreed
                                                                          Project Technology
                                                          Well                                         Highly
                                                         Proven                                       Uncertain
 August 16, 2010                                                                                                  17
Solution Functionality Used

•   Most of the functionality of
    delivered solutions is never
    or seldom used
      − Not surprising – think of all the
        features in applications such as
        Microsoft Office
      − How much do you use?
•   Represents a significant cost
•   Tendency is always to deliver
    complex feature-rich
    solutions
•   Simplicity is not seen as good


    August 16, 2010                         18
Agile Iterative Approach to Projects

•   Time is fixed for the life of a
    project and resources are
    fixed as far as possible
•   Requirements that will be
    satisfied are allowed to
    change
•   Flexibility of requirements to
    be satisfied has significant
    impact on the development
    processes and controls, and
    on acceptance of the system
•   Iterative approach reduces
    risk by continuously
    reaffirming and validating the
    solution being implemented


    August 16, 2010                    19
Agile Iterative Approach to Projects




 August 16, 2010                       20
What is Meant by Agility

•   Driven by user descriptions/scenarios of what is required
    of the solution
•   Seeks constant user feedback
•   Recognises that plans are short-lived
•   Develops solution iteratively with a emphasis on
    development activities
•   Delivers multiple working solution increments
•   Adapts as changes occur



    August 16, 2010                                             21
What Are the Potential Issues With Agile Approach

•   May not apply to large and complex projects
•   May not be suitable to all organisations and people
•   Delivered solutions may not be scalable to large volumes
    of users/transactions/workload/data
•   Delivered solutions may not be adaptable to meet future
    business needs




    August 16, 2010                                            22
Agile and People

• People are at the core of an agile process
• The process adapts to the needs of the team needs rather
  than imposing a structure on the team as with
  conventional sequential processes
• An effective agile team should be:
      − Competent
      − Working towards a common goal
      − Collaborative
      − Able to make decisions
      − Good at solving problems
      − Trust and respect one another
      − Self-organising with respect to workload, schedule and project
        processes
    August 16, 2010                                                      23
Iterative Agile Approach to Projects

•   Fundamental assumption of agile approach to projects is that
    nothing is built perfectly first time
•   80% of the solution can be implemented in 20% of the time that it
    would take to produce the total solution
•   All deliverables from previous project steps can potentially be
    revisited as part of the iterative approach
•   Only enough of the current step need be completed to move to the
    next step
•   Designed to address the current and immediate needs of the
    business
•   Deliver simpler solutions more quickly that are fit for purpose and
    easier to maintain and modify after their initial implementation

    August 16, 2010                                                       24
Agile Approach to Ensuring Project Success

•   Satisfies the real requirements of the organisation
    prioritised by importance
•   Supports the way the organisation needs to work
•   Aims to deliver quality solution on time and within budget
•   Aims to deliver quickly and effectively
      − Required functionality, performance, security, operability and
        maintainability




    August 16, 2010                                                      25
Using Agile Iterative Approach

•   All too frequently seen as a panacea to project problems
      − It is not
      − Agile is hard
•   Agile has become fashionable without an understanding of
    the effort involved
•   Agile requires commitment, involvement and can be
    intense and demanding
•   If you have current project problems, agile is probably not
    the solution
      − You need to fix the underlying organisational issues first


    August 16, 2010                                                  26
Agile Approaches

•   Lots of different agile approaches
      −    Adaptive Software Development (ASD)
      −    Agile Unified Process (AUP)
      −    Crystal Clear
      −    DSDM (Dynamic Systems Development Method)
      −    Essential Unified Process (EssUP)
      −    FDD (Feature Driven Development)
      −    Incremental SDLC
      −    Open Unified Process (OpenUP)
      −    RAD (Rapid Application Development)
      −    Scrum
      −    Spiral SDLC
      −    TDD (Test-driven development)
      −    XP (Extreme programming)
•   Common features
      − Teamwork, collaboration, and process flexibility adaptability throughout the project lifecycle
      − Divide tasks into smaller increments with accelerated planning
      − Multiple small iterations
•   Many agile processes are focussed on software development projects
•   Need a more generalised agile approach that can be applied to all information technology
    projects

    August 16, 2010                                                                                      27
Benefits of Iterative Agile Approach to Solution
Delivery
•   Users are more likely to be committed to the solution
•   Risk of building the wrong solution is substantially reduced
•   Final system is more likely to meet the real needs of the
    organisation
•   Implementation is more likely to be easier because of the
    involvement of all parties concerned throughout the
    project




    August 16, 2010                                                28
Agile Iterative Approach Structure
                                                    Generalised Approach to
                                                     Agile Iterative Projects


Project Selection and                 Control Components of                Agile Tools and
                                                                                                             Agile Phases
     Validation                           Agile Process                     Techniques


                        Agile Approach
                                                          Timeboxing                          Workshops                       Pre-Project
                      Suitability Checklist


                    Solutions and Projects           MoSCoW Prioritisation                                              Feasibility Analysis and
                                                                                        Models and Modelling
                      When to Use Agile                of Requirements                                                            Study


                      Agile Project Critical                                                                            Business Analysis and
                                                              Estimation                      Prototypes
                        Success Factors                                                                                        Study


                        Key Principles of             Project Management                                                    Functional Model
                                                                                                Testing
                    Iterative Agile Approach          and Project Planning                                                      Iteration


                                                                                             Configuration                  Design and Build
                                                       Risk Management
                                                                                             Management                         Iteration


                                                      Quality Management                                                    Implementation



                                                         Measurement                                                          Post-Project

  August 16, 2010                                                                                                                               29
Using Agile Effectively and Productively


                   Agile Approach     Solutions and
                     Suitability      Projects When
                      Checklist        to Use Agile




                    Agile Project     Key Principles
                   Critical Success     of Iterative
                        Factors       Agile Approach



 August 16, 2010                                       30
Checklist of Suitability of Projects for Agile Iterative
Approach
•   Do the sponsor and management understand and accept the agile philosophy as their buy-in is
    essential?
•   Will the team members be empowered to make decisions?
•   Is there senior user commitment to provide end user involvement?
•   Can the organisation accommodate the frequent delivery of increments?
•   Will it be possible for the project team to have access to the users throughout the project?
•   Will the project team remain the same throughout the project as stability of the team including the
    user representatives is important?
•   Will the project team have the appropriate skills including technical skills, knowledge of the business
    area?
•   Will the individual project teams consist of six people or less?
•   Will the project use technology suitable for prototyping?
•   Is there a highly demonstrable user interface?
•   Is there clear ownership?
•   Will the solution development be computationally non-complex as the more complex the development
    the greater the risks involved?
•   Can the solution be implemented in increments if required?
•   Has the development a fixed timescale?
•   Can the requirements be prioritised with a mix of Must Haves, Should Haves, Could Haves and Want to
    Have but Won't Have This Time?
•   Are the requirements not too detailed and fixed so users can define requirements interactively?
    August 16, 2010                                                                                           31
Solutions and Projects When to Use Agile

•   Solution that is interactive, where the functionality is clearly
    demonstrable at the user interface
      − Agile is based on incremental prototyping with close user involvement
      − User must be able to assess the functionality easily through viewing and
        operating working prototypes
•   Solution that has a clearly defined user group
      − If the user group is not clearly defined, there may be a danger of driving the
        solution from a wrong viewpoint or ignoring some important aspect of the
        project entirely
•   Solution that is computationally complex, the complexity can be
    decomposed or isolated
      − If the internals of the solution are hard to understand via the user interface
        then there is a risk
      − Level of computational complexity is often quite difficult to determine in
        advance
      − Interactions between different components that can be difficult to identify up
        front


    August 16, 2010                                                                      32
Solutions and Projects When to Use Agile

•   Solution that is large, possesses the capability of being split into smaller functional
    components
      − If the proposed solution is large it should be possible to break it down into small,
        manageable chunks, each delivering some clear functionality
      − These can then be delivered sequentially or in parallel
      − Each sub-project must be constantly aware of the overall system architecture
•   Solution that is time-constrained
      − There should be a fixed end date by which the project must be completed
      − If there is no real case for the end date to be fixed, it will be relatively easy to allow
        schedules to slip and the fundamental benefits of agile approach will be lost
•   Solution where requirements can be prioritised
      − Requirements should be able to be prioritised using the MoSCoW rules
•   Solution where requirements are unclear or subject to frequent change
      − In periods of rapid change it may be difficult to specify the requirements in detail at the
        outset of the project making traditional approaches unsuitable
      − Agile approach is designed specifically to deal with requirements that change and
        evolve during a project
      − Applications that are difficult to specify in advance because the users do not know
        exactly what is needed at the outset


    August 16, 2010                                                                                   33
Solutions and Projects When Not to Use Agile

•   Process control/real-time applications
•   Requirements that have to be fully specified before any
    programs are written
•   Safety-critical applications
•   Solutions aimed at delivering re-usable components




    August 16, 2010                                           34
Agile Project Critical Success Factors

•   Acceptance of the agile approach before starting work
•   Delegation of decision-making to the business people and
    developers in the development team
•   Commitment of senior business management to provide significant
    end-user involvement
•   Incremental delivery
•   Easy access by developers to end-users
•   Stability of the team
•   Project team should be highly skilled people in terms of both the
    business area as well as the technical environment
•   Size of the project team should be small in order to minimise the
    overheads of management and communication
•   Solution technology that allows iterative development,
    demonstrable work products and control of versions
    August 16, 2010                                                     35
Key Principles of Iterative Agile Approach

•         Iterative agile approach requires acceptance of key
          principles
      1. Active user involvement is essential
      2. Collaborative and co-operative approach between all
         stakeholders is essential
      3. Agile project team must be allowed make decisions
      4. Focus is on frequent delivery of products
      5. Fitness for business purpose is the essential measure for
         acceptance of deliverables
      6. Iterative and incremental development is necessary to converge
         on an accurate business solution
      7. All changes during solution implementation are reversible
      8. Requirements are baselined at a high level
      9. Testing is integrated and performed throughout the lifecycle
    August 16, 2010                                                       36
Principle 1 - Active User Involvement is Essential

•   Agile is user-centered
•   If users are not closely involved throughout the project
    lifecycle, delays will occur during decisions making
•   Users may feel that the final solution is imposed by the
    project team and/or their own management
•   Users are not outside the project team acting as suppliers
    of information and reviewers of results but are active
    participants in the project process
•   User and thus business commitment is fundamental to
    success

    August 16, 2010                                              37
Principle 2 - Collaborative and Co-operative
Approach Between All Stakeholders is Essential
•   The nature of agile projects means that low-level detailed
    requirements are not necessarily fixed when the team is assembled
    to perform the work
•   The short-term direction that a project takes must be quickly
    decided without the use of restrictive change control procedures
•   The stakeholders include not only the business and development
    staff within the project, but also other staff such as service delivery
    and resource managers
•   When development is procured from an external supplier, both the
    vendor and the purchaser organisations should aim for as efficient a
    process as possible while allowing for flexibility during both the pre-
    contract phase and when the contracted work is carried out
      − Can be difficult and needs substantial mutual trust

    August 16, 2010                                                           38
Principle 3 - Agile Project Team Must Be Allowed
Make Decisions
•   Project teams must be mixed and consist of both IT
    personnel and users
•   Project teams must be able to make decisions as
    requirements are refined and possibly changed
•   Project teams must be able to agree that defined levels of
    functionality, usability, etc. are acceptable without
    frequent need to refer to higher-level management




    August 16, 2010                                              39
Principle 4 - Focus is on Frequent Delivery of
Products
•   A product-based approach is more flexible than an activity-
    based one
      − Products include interim development products, not just
        delivered solutions
•   Work of a project team is concentrated on products that
    can be delivered in an agreed period of time
•   Enables the team to select the best approach to achieving
    the products required in the time available
•   By keeping each period of time short, the team can easily
    decide which activities are necessary and sufficient to
    achieve the right products
    August 16, 2010                                               40
Principle 5 - Fitness for Business Purpose is the
Essential Measure for Acceptance of Deliverables
•   Focus of agile is on delivering the necessary functionality
    at the required time
•   Traditional project focus has been on satisfying the
    contents of a requirements document and conforming to
    previous deliverables, even though the requirements are
    often inaccurate, the previous deliverables may be flawed
    and the business needs may have changed since the start
    of the project
•   Solution can be more rigorously engineered subsequently
    if such an approach is acceptable


    August 16, 2010                                               41
Principle 6 - Iterative and Incremental Development is
Necessary to Converge on an Accurate Business Solution

•   Agile iterative approach allows systems to grow incrementally
•   Therefore the project team can make full use of feedback from the
    users
•   Partial solutions can be delivered to satisfy immediate business
    needs
•   Agile approach uses iteration to continuously improve the solution
    being implemented
•   When rework is not explicitly recognised in a project lifecycle, the
    return to previously "completed" work is surrounded by controlling
    procedures that slow development down
•   Rework is built into the agile iterative approach process, the solution
    can proceed more quickly during iteration

    August 16, 2010                                                           42
Principle 7 - All Changes During Solution
Implementation are Reversible
•   To control the evolution of all products (documents,
    software, test products, etc.), everything must be in a
    known state at all times
      − Configuration management must be all-pervasive
•   Backtracking is a feature of agile iterative approach
      − Sometimes it may be easier to reconstruct than to backtrack
        depending on the nature of the change and the environment in
        which it was made




    August 16, 2010                                                    43
Principle 8 - Requirements are Baselined at a High
Level
•   Baselining high-level requirements involves "freezing" and
    agreeing the purpose and scope of the system at a level
    that allows for detailed investigation of what the
    requirements imply
•   Further, more detailed baselines can be established later
    in the project
      − The scope should not change significantly
•   Changing the scope defined in the baselined high-level
    requirements generally requires escalation



    August 16, 2010                                              44
Principle 9 - Testing is Integrated and Performed
Throughout the Lifecycle
•   Testing is not treated as a separate activity
•   As the solution is developed incrementally, it is also tested
    and reviewed by both the project team and users
    incrementally
      − Ensures that the project is moving forward not only in the right
        business direction but is also technically sound
•   Early in project lifecycle, the testing focus is on validation
    against the business needs and priorities
•   Towards the end of the project, the focus is on verifying
    that the whole system operates effectively – system and
    integration testing
    August 16, 2010                                                        45
Control Components of Agile Process

• Since agile iterative projects are flexible in their
  development activities all aspects of their management
  need to be flexible while maintaining a level of control that
  ensures successful delivery of the required business
  solution
• Key control techniques and components
      − Timeboxing
      − MoSCoW prioritisation of requirements
      − Estimation
      − Project management and project planning
      − Risk management
      − Configuration management
      − Measurement
    August 16, 2010                                               46
Timeboxing

•   Very important aspect of agile iterative process and projects
•   Process to reach defined objectives at a pre-determined and fixed date through
    continuous prioritisation and flexing of requirements using the MoSCoW control
    rule
•   Timebox is a fixed interval of time - typically between two and six weeks in length
    but the shorter the better
•   Without the control of timeboxing, project teams can lose their focus and run out
    of control
•   Used at various stages of project
      − Project end-date is fixed and the overall business objectives to be achieved by that date
        are defined
      − End date for each increment within the project is fixed and the prioritised set of
        business and technical requirements to be satisfied by that date are defined
      − End date for phase level activities is fixed, e.g. for the Feasibility Study, and the
        objectives for this project defined
      − End date for part of the prototyping activity is fixed and the prototype is created,
        reviewed and tested according to the objectives defined in the timebox schedule
        contained in the Development Plan
      − End time for a workshop, meeting or review is fixed and the participants work to the
        predefined and prioritised objectives

    August 16, 2010                                                                                 47
Timeboxing

•   A timebox must have an agreed scope and clear objectives based on a subset of
    the prioritised requirements list
•   With timeboxing control is not activity-based
•   Objective of a timebox is to make a product - produce something tangible in order
    for progress and quality to be assessed
•   How that product is put together will be decided by the people doing the work, as
    long as the project's standards and procedures are followed
•   Team working in the timebox must agree the objectives and must themselves
    estimate the time required
•   At the deadline, the users must be able to approve the delivery of the products
    covered by the timebox
•   If it appears that deadlines could be missed, the deliverable should be de-scoped
    dropping the lower priority items
•   Detailed planning of a subsequent timebox containing dependent work cannot be
    started before the current timebox is complete


    August 16, 2010                                                                     48
Timebox Plan

•   Plan for an individual timebox within Functional Model and
    Design and Build Iteration phase
•   Purpose and objectives
•   Define the products of an individual timebox
•   Define key milestones, e.g. technical or user review dates,
    within a timebox
•   Agree the prioritisation of products and activities within a
    timebox



    August 16, 2010                                                49
Timeboxing and Daily Meetings

•   During each timebox, the team working on the timebox should meet
    daily to review their progress and to raise issues
      − Provides the team with evidence regarding their progress and the problems
        they face
      − Highlight risks as they occur
      − Each daily meeting should be limited at 30 minutes and ideally lasts no longer
        than 15 minutes
      − All team members attend
•   Agenda
      − What work has been completed for this timebox since the last daily meeting?
      − What (if anything) got in the way of completing the planned work?
      − What work will be done between now and the next daily meeting?




    August 16, 2010                                                                      50
Timebox Plan Questions and Checklist

•   Are the estimates of effort reasonable? Were they produced by the
    people doing the work?
•   Have acceptance criteria been agreed for the products of the
    timebox? If they have not, is it clear when these will be available?
•   Is there a high degree of certainty that the Must Haves will be
    created, developed and tested to the required standard?
•   Are the review dates agreed with all key personnel?
•   Have lessons learnt in previous timeboxes been applied?
•   Can the team commit to delivering at least the Must Haves by the
    agreed end date?



    August 16, 2010                                                        51
MoSCoW Prioritisation of Requirements

•   MoSCoW
      − Must Have
             •    Requirements that are fundamental to the system
             •    Without them the system will be unworkable and useless
             •    Must Haves define the minimum usable subset
             •    Agile project guarantees to satisfy all the minimum usable subset
      − Should Have
             • Important requirements for which there is a workaround in the short term
               and which would normally be classed as mandatory in less time-constrained
               development, but the system will be useful and usable without them
      − Could Have
             • Requirements that can more easily be left out of the increment under
               development
      − Want to Have but Won't Have This Time
             • Requirements that can wait till later development takes place - the Waiting
               List
    August 16, 2010                                                                          52
MoSCoW Prioritisation of Requirements

•   Delivering on a guaranteed date means that what was originally envisaged for an
    individual delivery may have to be left out
•   Important that essential work is done and that only less critical work is omitted
•   Means of ensuring that this is true is clear prioritisation of the requirements
•   Provides a basis on which decisions are made about what the project team will do
    over the whole project, within an increment of the project and during a timebox
    within an increment
•   As new requirements arise or as existing requirements are defined in more detail,
    the decision must be made as to how critical they are to the success of the current
    work using the MoSCoW approach
      − All priorities should be reviewed throughout the project to ensure that they are still
        valid
•   Essential that not everything to be achieved within a project or a timebox is a
    Must Have
      − Having lower level requirements that enable teams to deliver on time by dropping out
        lower priority requirements when problems arise


    August 16, 2010                                                                              53
MoSCoW Prioritisation of Requirements

                                 •   Solution
                                     functionality is
                                     prioritised and
                                     delivered according
                                     to available time
                                     and resources but
                                     time and resources
                                     are fixed




 August 16, 2010                                           54
Estimation

•   Estimation provides the information that is required for
    two main purposes:
      − Assess project feasibility by evaluating costs and benefits
      − Use in project planning, scheduling and control
•   Estimation in agile iterative projects
      − Estimates should be tight from the outset with frequent
        deliverables
             • Not unacceptable for activity overrun and for long timescales for agreeing
               the quality of products
      − Estimates that are based on outline business functions provide
        the closest match with the agile iterative process
             • Starting point for estimating should be the expected functionality of the
               end products rather than the activities used to deliver those products

    August 16, 2010                                                                         55
Estimation

•   Estimation is a conditional forecast based on the information available at the time
      − An extrapolation from past and current knowledge to the future
      − Cannot be done with complete certainty because the future is unknown, therefore the
        actual effort or cost to deliver will almost always be different to the estimate
      − Better the quality of the information available for estimating, the closer the estimate is
        likely to be to the actual figures
•   Estimation must be based on a defined process so that it is rigorous and
    repeatable
      − Whatever process is used the primary information required to estimate is:
             • Scope of what is to be delivered
             • Delivery capability
•   Contingency must be included in any estimate in order for it to be realistic
      − estimates are conditional forecasts that will be affected by future events both internal
        and external to the project
      − Events cannot be known with certainty and the estimate must make reasonable
        allowance for them
      − Solution development itself is not an exact science
      − The size of the contingency in an estimate must reflect the degree of uncertainty

    August 16, 2010                                                                                  56
Estimation

                     Before the project begins properly an estimate must be prepared for the work to be done
 Pre-project Phase   during Feasibility Study phase
    Estimation       Estimate could be a timebox - a fixed team for a fixed period - or could be based on a schedule
                     of workshops and the associated effort to complete the products




                     First estimate for the whole project is prepared towards the end of Feasibility Study
 Feasibility Study
 Phase Estimation    Rough estimate, based on high level requirements - assist management to assess the value and
                     practicality of continuing with the project



                     Second estimate is produced at the end of the Business Study - scope of the project is decided,
                     the necessary business functionality to be delivered is defined and prioritised, and the system
                     architecture is defined
                     Detailed estimate as it based on the likely major components of the delivered solution
  Business Study     identified from the prioritised requirements
 Phase Estimation
                     Estimate must reflect a level of risk and confidence that is acceptable to the relevant
                     stakeholders
                     Purpose of this estimate is to plan and schedule the project and used to re-evaluate the
 August 16, 2010     Business Case to assess whether the project is still viable                                   57
Estimation
                     Detailed estimate from Business Study provides the basis for the whole project, and
                     throughout the remainder of the project this estimate is frequently monitored and revised
 Functional Model    Estimation is performed for each timebox to assess whether the timebox plan is achievable,
  Iteration Phase    and to evaluate the impact on the project if any revisions to the estimate are required
  and Design and
   Build Iteration   Before the start of each timebox an estimate for the expected work is carried out to ensure
 Phase Estimation    that it remains achievable in light of project experience to date
                     If there is significant deviation from the estimates, the original estimates should be carefully
                     reviewed



                     Until the Implementation Plan is prepared during Functional Model Iteration, there are only
 Implementation      very high level estimates available for this phase
 Phase Estimation    Before the Implementation phase begins, the estimates must be reviewed to ensure they are
                     still reasonable




 August 16, 2010                                                                                                        58
Estimation Techniques

•   Top Down - estimating by comparison where the proposed project is compared to
    similar completed projects
      − Based on the business requirements (rather than system components)
      − Give a figure for the project as a whole, which may be broken down into phases on a
        pro rata basis
      − Fast to prepare
      − Can be derived from very high level requirements
      − Give a high level view of the project (its overall cost and timebox) which can be used in
        evaluating the feasibility of the project
•   Bottom Up - counting components and other implementation-related information
    shown in a design and estimating the effort for each of those
      − Based on tangible system components
      − Give detailed figures for low level components of the project which can be aggregated
        to give higher level views
      − Take time to prepare
      − Need sufficiently detailed information to allow identification of system components
      − Provide a good basis for project planning, scheduling and management


    August 16, 2010                                                                                 59
Collaborative Estimation

•   Facilitated workshop can be an excellent approach to
    gaining both sound estimates and buy-in to these
    estimates from the team and the stakeholders
•   Participants should, between them, have expertise in all
    the main technical and business areas covered by the
    project
•   Project management and estimation participants
•   Estimation workshops require considerable preparation in
    order to achieve their objectives


    August 16, 2010                                            60
Estimation Guidelines

•   Use more than one technique to allow cross-checking, e.g. top-down and bottom-up
•   Produce estimates by workshops involving all stakeholders, rather than by individuals
•   Ensure the estimate includes sufficient effort for all timebox activities not just those directly
    resulting in business functionality, including
      −    Project management, team leading, technical co-ordination
      −    User involvement
      −    Non-functional requirements and technical products
      −    Specialist roles, such as business and technical consultants, quality and test managers, security
           specialists, etc.
      −    Specialist roles, such as business and technical consultants, quality and test managers, security
           specialists, etc.
      −    Workshop preparation, attendance and follow up, including facilitation and scribing
      −    Completion of project documentation
      −    Quality reviews, inspections, walkthroughs, timebox planning and estimating
      −    Travel and meetings particularly if cross-site
      −    Mentoring if project and/or organisation is new to agile iterative projects
      −    Specialist testing such as stress and performance, or operational acceptance.
•   Ensure all areas of development are included: avoid focus on pure coding effort
•   Capture project metrics and feed back actuals vs. estimates into the estimating process
•   Ensure that anyone who estimates is trained, particularly for specialist techniques such as
    function point analysis

    August 16, 2010                                                                                            61
Project Management

•   Aim of project management is to deliver the right solution on time
    and on budget using the available resources wisely
•   Management of traditional projects is about control
      − Preventing drift from the signed off specification, controlling resources, etc.
•   Managing an agile project is about enabling constant change while
    continuously correcting the course of the project in order to
    maintain its aim at the target - a fixed delivery date for a usable
    system
•   To be successful with agile iterative approach, the organisation may
    have to change organisational, social and technical elements at the
    same time
•   All impact on the management of the project

    August 16, 2010                                                                       62
Project Management

•   For tradition projects, the project manager has a detailed plan
    against which to monitor and control activities
•   In an agile and iterative project, there are typically more activities
    going on in parallel
      − Project Manager has a number of distinctive responsibilities to ensure that the
        project is under control in each phase
•   Speed of progress can pose some difficulties for managers from a
    traditional background in IT project management
      − If problems arise during a timebox then it is often tempting for the traditional
        manager to renegotiate the end date as that is what they would normally do
      − In an agile project, the timebox deadline is fixed usually because it is set by the
        business need
      − Consequently, the approved approach is to renegotiate the content of the
        timebox rather than its duration

    August 16, 2010                                                                           63
Project Management

•   In the agile iterative collaborative approach, there is a great deal of
    interaction between users and implementers in task completion
•   Important that communication is clear and concise if rapid
    development is to be achieved
•   Agile projects should have an informal but planned communication
    process
•   As each timebox is completed, it is the responsibility of the Project
    Manager to ensure that there is a clear understanding about what is
    to be delivered in the following timeboxes and to ensure that the
    relevant requirements are established in detail
      − Likely that the users will change their minds about priorities and requirements
      − Project Manger must be open to making such changes whilst ensuring that any
        consequences are fully understood by the users

    August 16, 2010                                                                       64
Project Management
                     •   Initial planning
                     •   Verify suitability of profile for agile approach
                     •   Agree project review and termination evaluation and decision factors
Pre-project Phase    •   Confirm user involvement
                     •   Give training in agile approach for all people new to the method
                     •   Schedule workshop facilitators



                     •   Set up the Feasibility Study team
                     •   Attend all workshops
                     •   Review/accept and get signoff for the Feasibility Report
 Feasibility Study   •   Ensure that all key stakeholders have bought in to the Prioritised Requirements List and
      Phase              the proposed timescales for (incremental) delivery for the project
                     •   Create a high-level Business Case for the project
                     •   Create the Outline Plan
                     •   Schedule Business Study workshop


                     •   Manage production of the Business Study products
                     •   Attend all workshops
                     •   Review and update project risks
  Business Study     •   Create the Development Plan jointly with all relevant people
                     •   Refine the Business Case and get it agreed by the relevant people
      Phase          •   Obtain agreement to proceed into development
                     •   Ensure that all project Team Leaders are aware of the contents of the Business Case so
                         that they can use it as the basis for negotiation about what is important within their
                         timeboxes
 August 16, 2010                                                                                                    65
Project Management
                    •   Agree individual Timebox Plans with the Team Leaders
                    •   Participate in timebox kick-off and closeout meetings
Functional Model    •   Accept all timebox deliverables to the project at each timebox closeout meeting
                    •   Monitor the team(s)
 Iteration Phase    •   Create the Implementation Plan jointly with all relevant people
                    •   Publish the Implementation Plan and get it agreed by the relevant people before the end
                        of the last pass through the Functional Model Iteration




                    •   Agree individual Timebox Plans with the relevant Team Leader
 Design and Build   •   Participate in Timebox kick-off and closeout meetings
  Iteration Phase   •   Accept all timebox deliverables to the project at each timebox closeout meeting
                    •   Monitor the team(s)




                    •   Manage the migration of the system to the operational environment
                    •   Ensure all necessary training takes place in a timely way
 Implementation     •   Run the Increment Review workshop and produce the Increment Review Document
      Phase         •   Obtain sign-off of the increment from all relevant parties
                    •   Plan the next increment if there is one
                    •   For the last increment, set the date for the Post-Implementation Review

 August 16, 2010                                                                                                  66
Project Management

                     •   Ensure all lessons learnt are made available to other projects
Post-project Phase   •   Participate in the Post-Implementation Review




 August 16, 2010                                                                          67
Project Planning

•   The purpose of project planning is to ensure the success of the project
•   For agile projects planning is not just an activity that takes place at the beginning
    of the project - it continues throughout the lifecycle
•   Planning an agile project can be especially difficult for a project manager used to
    traditional methods
•   Agile project plans evolve with more and more detail as the project progresses, as
    requirements are progressively refined and as lessons are learnt
•   Plan should address all products generated by, and activities undertaken in, the
    project
      − Includes the deliverable products (prototypes, models, documentation, etc.)
             •    Project initiation
             •    Configuration management
             •    Change control
             •    Product breakdown structure
             •    Product descriptions
             •    Risk management
             •    Work instructions


    August 16, 2010                                                                         68
Project Planning

•   Traditional project planning
      − Focus on agreeing a detailed "contract" with customers about the totality of
        the system to be delivered along with the costs and timescales
      − Concerned with understanding the requirements in complete detail so that the
        right level of resources can be secured and an estimate of the completion time
        can be made
      − Plan is created in a great detail and is ideally executed with minimal change
•   Agile project planning
      − Focus on setting up a collaborative relationship with the customers, bringing
        them fully into the make-up of the team
      − Concerned with agreeing with the users the process by which the business
        requirements will be met
      − Initial plans are created in sufficient detail to establish the main parameters of
        the project and with the firm expectation that the customers will change the
        plan during the course of the project as they gain a deeper understanding of
        their needs


    August 16, 2010                                                                          69
Pre-project Phase Planning

• Objective of pre-project planning is to provide the basis for
  carrying out the project successfully
• Understand the requirements just sufficiently to assess the
  risks and suitability of the project for an agile approach
• Establish the right conditions for the project with the user
  management
• Ensure that the managers from the business have agreed
  to release their staff into the development team for
  significant periods of time (including full-time secondment
  when the project requires it)
• Agree a definition of "fitness for business purpose" for the
  system being developed with the business
    August 16, 2010                                               70
Agile Project Plans

                      Outline Plan
 Feasibility Study
      Phase           Means to define and agree the terms and conditions for a successful project and
                      contains as a detailed plan for the Business Study


                      Development Plan
  Business Study
      Phase           How the project will be carried out and in particular which prototypes will be built
                      and when

 Functional Model     Timebox Plan at the start of each timebox
Iteration Phase and
  Design and Build    Refines the Development Plan where each Timebox Plan contains at least one
      Iteration       complete cycle of the Functional Model Iteration or Design and Build Iteration for
        Phase         part of the system


 Implementation       Implementation Plan
      Phase           Defines how the successful implementation of the solution will be achieved


 August 16, 2010                                                                                             71
Agile Planning Success Factors

•   The contents of timeboxes are crucial
•   Plan for deliverables and not activities
      − Consider the key questions "who, when what, where, how" when planning
•   Define quality criteria for each deliverable
•   Plan for frequent delivery of products
      − Distinguish "delivery to the project" from "delivery to the end user population"
•   Focus of planning and control in agile projects is on sustaining a high rate of progress, agreeing
    priorities, keeping relationships healthy, learning as the project progresses, and allowing plans to
    evolve based on experience gained
•   Make project planning work by focusing on principles, products, and people rather than methods and
    techniques
•   Manage expectations by planning appropriate briefings and training on agile approach, addressing
    roles and responsibilities, and defining and agreeing products and acceptance criteria
•   Plan for the use of experienced mentors where there is insufficient experience in the team
•   Plan to do the work during normal working hours
•   Plan contingency only for prerequisites (software, hardware, setup, etc.) but not for time or resource
    on the project itself
      − Contingency in agile is managed through prioritisation of requirements
•   Plan for regular daily team meetings
•   Plan formal reviews at the end of each timebox and establish dates in diaries early
•   Plan early for testing interfaces, theoretical performance analysis, and performance prototyping

    August 16, 2010                                                                                          72
Agile Planning Problems

•   Objectives and requirements that are either too vague or
    too detailed
•   Failure to architect the approach
•   Frequent changes to the schedule for user involvement
•   Incomplete and conflicting information
•   Introducing too much change at one time




    August 16, 2010                                            73
Risk Management

• Ongoing process throughout the life of a project
• Actively control all the risks facing a project or the
  implementation of the solution it is delivering
      − Identification of any and all risks that may threaten the project for
        business, systems or technical reason
      − Assessment of the impact of those risks on the success of the
        project should they arise and deciding on the likelihood of the risk
        occurring and if it does on the severity of its impact on the project
      − Management of those risks through defining specific
        countermeasures that are aimed at either avoiding the identified
        risks or accepting them and minimising their detrimental effect on
        the project
      − Applying the appropriate countermeasures when a risk
        materialises

    August 16, 2010                                                             74
Risk Management

•   Risks must be identified and their impact assessed as early as
    possible
•   Risks should be continuously reviewed throughout the life of the
    project, particularly at critical go/no go decision points within the
    project such as the end of the Business Study and before initiating
    the development of a new increment
•   All risks should be assessed in terms of their potential impact
•   Risks must be actively managed through countermeasures to
    minimise their possible impact
•   The emphasis of risk management activities should be on the risks
    with the highest levels
•   Projects with risks determined as unacceptable by the Executive
    Sponsor should not be started
•   Projects whose risks rise to an unacceptable level should be stopped

    August 16, 2010                                                         75
Risk Log

•   Opened at the start of the project to assist management in deciding the future of
    the project
      − Class of risk (business, systems or technical)
      − Description of the risk - should be in sufficient detail to be understood by all interested
        parties but short enough to enable a checklist approach to risk monitoring throughout
        the project
      − Likelihood of the risk occurring (high, medium or low)
      − Severity of impact on the project should the risk occur (high, medium or low)
      − One or more proposed countermeasures, which will mitigate the risk either by
        preventing it occurring or by containing when it arises
             • Countermeasures should include the dates beyond which they are no longer applicable
      − The status of the risk (open or closed), open risks are still possible, closed risks have
        either happened and have been dealt with or the time at which they were likely to
        happen has passed
      − Owner of the risk (who is responsible for monitoring the risk and/or implementing any
        countermeasures)
•   Checklist
      − Are all the factors potentially affecting the success of the project discussed?
      − Are risks sufficiently quantified for a decision to be made?
      − Does each risk have at least one countermeasure identified?


    August 16, 2010                                                                                   76
Quality Management

•   Quality of an information technology solution often defined in terms
    of the way in which that system provides the capability and support
    required by the user
•   Agile approach designed to ensure the quality of the project's
    products
      − Facilitated workshops ensure that the system's requirements are properly
        considered at the outset
      − Continuous and focused user involvement helps to ensure that all parties
        understand each others - needs and viewpoints
      − Reviews (whether of prototypes or of supporting documentation) serve to
        ensure (and record) that the system continues to meet the needs of the
        business - the quality criteria against which products should be reviewed are
        identified the Product Descriptions
      − Thorough testing validates the delivered system against its requirements
      − Configuration Management and Change Control serve to ensure that quality,
        once built in to the system, is preserved

    August 16, 2010                                                                     77
Quality Planning

•   Quality planning should be an integral part of the project planning
    activity
      − Identification of which products are to be produced and which of those
        warrant specific quality-related activities
      − How the quality of each type of product is to be checked - for example by
        review and/or by testing
      − When quality checks are to be performed; and whether they are they optional
        or mandatory, whether or not all examples of a particular type of product must
        be checked or only a sample, and whether items are checked during
        development or only on completion
      − Who is responsible for reviewing and testing each product, who has authority
        to accept the product and what is to happen if such a review or test is
        unsuccessful
      − Which criteria are to be used to assess each product's quality - typically by
        reference to the quality criteria defined in each of the Product Descriptions
      − Which procedures are to be used to define quality-related processes
      − Which records are to be kept to document decisions and actions taken
      − Which standards are to be applied to products (for example, coding standards
        and user interface style guides)

    August 16, 2010                                                                      78
Quality Audits

•   Audit projects from time to time in order to determine their
    compliance with the organisation's procedures, practices and
    standards
•   Very important in agile projects that such audits are not allowed to
    result in unnecessary rework or ineffective effort expenditure
•   Greatest benefit obtained from audits is frequently in causing
    corporate procedures, practices and standards to be revised in the
    light of real experience
•   Agile-specific audit questions
      −    Is the user involvement there?
      −    Are the users empowered?
      −    Is the life-cycle being followed?
      −    Are comments from prototype reviews being incorporated?
      −    Is backtracking allowed when necessary?
      −    Are priorities being adhered to?
      −    Are timeboxes being respected?

    August 16, 2010                                                        79
Measurement

•   Measurement is necessary in order to:
      − Establish a baseline for predicting what will happen in the future
      − Provide evidence that the process is successful and working
      − Investigate the process itself in order to highlight and quantify problems
•   Can provide the information to convince management that the
    introduction of agile iterative approach can provide tangible benefits
    to the organisation
•   Projects should keep careful records of defects classified by severity
    and type
•   Success of a project will be whether or not it achieved the stated
    objectives so these should be described in precise measurable terms
      − Agile approach is focused on satisfying all of the "must haves" within a fixed
        elapsed time frame so any measurement of success needs to include all of
        these


    August 16, 2010                                                                      80
Agile Tools and Techniques

•   Tools and techniques that are applied to agile projects
      − Workshops
      − Models and Modelling
      − Prototypes
      − Testing
      − Configuration Management




    August 16, 2010                                           81
Workshops

•   Workshop is a structured approach to ensure that a group of people can reach a predetermined
    objective in a compressed timeframe supported by an impartial facilitator
•   Benefits
      − Rapid, quality decision-making
             •    Because all stakeholders are present at the same time, there is great confidence in the result
             •    Group is focused on the objectives to be achieved in the session so that the information gathering and review cycle is
                  performed at a greater speed
             •    Misunderstandings and disagreements can be worked out at the time
             •    Concerns should therefore have been raised and resolved or noted by the end of the workshop
      − Greater user buy-in
             •    Workshops, run effectively, lead to participants feeling more involved in the project and decisions being made
             •    Build and maintain enthusiasm
      − Building team spirit
             •    Controlled way of building rapport as well as delivering
             •    Promotes understanding and co-operation between departments - important when a solution involves many groups
      − Process redesign by the user community
             •    If practices are reviewed as a result of a workshop, participants can gain a greater understanding of the inputs and implications
                  of their work
             •    Leads to improved efficiencies that are led by the participants themselves, giving greater buy-in and commitment
             •    Greater chance of successful implementation
      − Clarification of requirements when they are unclear
             •    Business users can be led through their objectives and processes to define what they may require
             •    Participants can explore and model ideas
             •    Successful through a combination of structured discussion and the presence of knowledgeable participants




    August 16, 2010                                                                                                                                   82
Applying Iterative Agile Principles to Workshops
•   Active user involvement is essential
      −    Workshops provide an ideal format for the business to be directly involved in planning, designing and implementing a solution
•   A collaborative and co-operative approach between all stakeholders is essential
      −    Create a climate of co-operation within the workshop and enforcing any ground rules for the group to behave effectively
      −    Only possible with the co-operation and commitment of all stakeholders
      −    Effective way of achieving either compromise or consensus
•   Agile project team must be allowed make decisions
      −    Workshop participants need to be empowered and have the right level of knowledge and authority within the scope of the workshop, so that decisions can be
           made without delay
•   Focus is on frequent delivery of products
      −    Structure a workshop so that there are intermediate deliverables
      −    Helps to order participants' thinking as they progress in logical steps
      −    Enables them to work towards an ultimate goal and gives them a growing sense of achievement as the workshop progresses
•   Fitness for business purpose is the essential measure for acceptance of deliverables
      −    Fitness for purpose is achieved by keeping participants focused on delivery against an agreed set of objectives
      −    Ensure all are involved in decision-making
•   Iterative and incremental development is necessary to converge on an accurate business solution
      −    Strength of workshops is the synergy achieved by the group
      −    Ideas do not have to be born fully developed but can grow during discussion
      −    Ideal setting to try out ideas with all stakeholders and it is up to the facilitator to provide a safe environment in which this can happen
•   All changes during solution implementation are reversible
      −    Information and decisions should be recorded as necessary by either one or both of the facilitator and scribe so that ideas can be backtracked where necessary
      −     Often what happens in practice is that an idea or decision is redeveloped
•   Requirements are baselined at a high level
      −    Objectives must be set during the preparation for a workshop
      −    As the workshop progresses, information is gathered, analysed and interpreted so that discussion can be effective and a decision reached as a result of an
           increased understanding of the issues involved
•   Testing is integrated and performed throughout the lifecycle
      −    Because all stakeholders are present, workshop provides the quality control approach of testing ideas and deliverables as they are discussed
      −    Participants can challenge or agree




    August 16, 2010                                                                                                                                                         83
Models and Modelling

•   Modelling helps the project team gain a good understanding of a business
    problem, issue or process
•   Accurate models reflect the realities of the business world
•   Understanding can be gained by analysing the problem from different viewpoints
      − Business View - uses a selection of techniques to understand and interpret the business
        need and to model the business from a future perspective
      − Processing View - models the system as a set of business processes, or activities, which
        transform input data items to output data items
             • Processes can be either combined to form higher level processes, which in turn can be
               combined again to form yet higher level processes, or decomposed into their constituent sub-
               processes
             • Corresponds to the traditional "Why, What and How" type of questioning used during
               requirements elicitation
      − Data View - models the business information as a set of objects, or entities, and the
        relationships that exist between these objects
      − Behavioural View - models the behavioural characteristics of the system in terms of a
        set of events and states, where events cause changes in the states of the system. Events
        may be generated within or external to the system
      − User Interface View - models the interactions and interfaces between the system user
        and the system itself


    August 16, 2010                                                                                           84
Prototypes

•   Prototypes provide the mechanism through which users can ensure
    that the detail of the requirements is correct
•   Demonstration of a prototype broadens the users' awareness of the
    possibilities for the new system and assists them in giving feedback
    to the project team
•   Accelerates the development process and increases confidence that
    the right system is being built
•   Types of prototype
      − Business - demonstrating the business processes being automated
      − Usability - investigating aspects of the user interface that do not affect
        functionality
      − Performance and Capacity - ensuring that the system will be able to handle full
        workloads successfully
      − Capability/Technique – testing a particular design approach or proving a
        concept

    August 16, 2010                                                                       85
Testing

•   In agile projects testing takes place throughout the project
    lifecycle
      − Validation - check that a system is fit for business purpose
      − Benefit-directed testing - testing the parts of the solution that
        deliver the key business benefits is the highest priority
      − Error-centric testing - objective of designing and running a test is
        to find an error
      − Testing throughout the lifecycle - performed on all products at all
        stages of the project
      − Independent testing - a product should be tested by someone
        other than its creator
      − Repeatable testing - tests must be repeatable

    August 16, 2010                                                            86
Testing

•   Testing activities must be prioritised based on the business goals
      −    Overall business process performance (i.e. business processing cycle times)
      −    Large processing volumes (i.e. very frequently occurring events)
      −    Labour-intensive or complex business tasks
      −    Human computer interface, particularly if the computer system will be visible
           to customers
•   Efficient use of time available can be made through risk based
    testing
      −    Identify the risk areas
      −    Assess the impact of errors
      −    Plan for risk based testing
      −    Reduce the risk of errors



    August 16, 2010                                                                        87
Configuration Management

•   Dynamic nature of ale projects means good configuration
    management is required
•   Many activities are happening at once and products are
    being delivered at a very fast rate
•   Configuration management strategy must be decided and
    documented in the Development/Implementation Plan
    before leaving the Business Study phase




    August 16, 2010                                           88
Iterative Agile Framework

•   Solution delivery lifecycle is iterative and incremental
•   Solution is not be delivered in one go, but in a series of
    increments, which increase what it does each time
•   Urgent business needs are addressed early while less
    immediately important functionality is delivered
•   Users see work under construction, review and comment
    on it and request changes during the development of an
    increment
•   Agile approach provides a generic framework for iterative
    solution delivery

    August 16, 2010                                              89
Overall Agile Iterative Process - Phases

1.         Pre-Project
2.         Feasibility Analysis and Study
3.         Business Analysis and Study
4.         Functional Model Iteration
5.         Design and Build Iteration
6.         Implementation
7.         Post-Project



     August 16, 2010                        90
Overall Agile Iterative Process
                                                                         6


                       2                                 Implementation
                                     4
                    Feasibility                                                           7
       1           Analysis and
                      Study
                                  Functional
                                     Model                                       Post-Project
Pre-Project                        Iteration

                    Business
                   Analysis and
                      Study                                 Design and
                                                               Build
                                                             Iteration
                   3
                                                                             5
                   Sequential                  Iterated Phases
                     Phases
 August 16, 2010                                                                                91
Iterated Phases
                    Agree How                                                                   Agree How
                   and When To                                                                 and When To
                       Do It                                                                       Do It



                   Functional       Identify                                                                 Identify
 Create                                                                               Create
  The                 Model         What Is
                                                                                       The   Implementation What Is
                                                                                                              To Be
                                     To Be
Product             Iteration                                                        Product
                                   Produced                                                                 Produced


               Check That It Has                                                             Check That It Has
                Been Produced                               Agree How                         Been Produced
                  Correctly                                and When To                          Correctly
                                                               Do It



                                                           Design and         Identify
                                                Create                        What Is
                                                 The          Build
                                                            Iteration          To Be
                                               Product
                                                                             Produced


                                                         Check That It Has
                                                          Been Produced
                                                            Correctly
 August 16, 2010                                                                                                        92
Agile Iterative Sequential and Parallel Phases

                                                         Functional Model Iteration Phase


                     Feasibility     Business
Pre-Project                                                                                         Post-Project
                    Analysis and   Analysis and          Design and Build Iteration Phase
  Phase                                                                                                Phase
                    Study Phase    Study Phase


                                                              Implementation Phase




           Increment 1                     Increment 1                                       Increment 1


           Increment 2                     Increment 2                                       Increment 2



                                                                    Final Increments Prior   Increment P
                                           Increment M                      to Final
                                                                       Implementation
           Increment N

  August 16, 2010                                                                                                  93
Phase 1 - Pre-Project Phase

•   Ensures that only the right projects are selected and that
    they are set up correctly to ensure success
•   Initial definition of the business problem to be addressed
•   Decision to proceed with the project
•   Project manager assigned to the project
•   Initial project governance in place




    August 16, 2010                                              94
Phase 2 - Feasibility Analysis and Study Phase

•   Assessment if iterative agile is the right approach for the
    project
•   Feasibility Study should be short and should last no more
    than a few weeks
•   Consider using workshop(s) to perform feasibility analysis
•   Feasibility Study outputs
      − Feasibility report
      − Outline plan for implementation
      − Feasibility prototype
      − Solution risk log


    August 16, 2010                                               95
Feasibility Analysis and Study Report

•   Enables the project steering committee to decide not only which option to choose for the
    way forward and whether or not the project should proceed beyond the Feasibility Study
•   Objectives and purposes
      − Outline the problem to be addressed by the new system
      − Define the scope of the project or set of projects
      − Give a preliminary indication of any areas within the scope which may be desirable but not
        essential
      − State, at least in outline, the Business Case for the project(s) - including where possible expected
        costs, benefits, assumptions and risks (whether quantifiable or not)
      − Indicate what alternative solutions have been or could be considered
      − Define the major products to be delivered by the project
      − Report on the suitability of an agile approach for use on the project, which may vary for each
        solution
      − Document the objectives of the project including process performance criteria
      − Document high-level technical and business constraints, e.g. timescale, hardware and software
        platforms
      − Identify whether the system may be safety-related or if there may be any product liability issues
      − Describe at a high level the business processes and data that are expected to be automated
      − Identify at a high level the interfaces necessary to existing data and applications
      − Identify which business processes and/or systems (whether automated or not) might be impacted
        by the new system and which might need to change in order to accommodate it
      − Define the expected life of the computer system and hence the requirements for maintainability


    August 16, 2010                                                                                            96
Feasibility Analysis and Study Report Questions and
Checklist
•   Is the problem definition in line with the needs of senior business management?
•   Is the scope of the project sufficiently clear for it to be refined within the Business
    Study?
•   Are the business objectives to be met by the development clearly defined?
•   Is the solution to the problem, as laid out in the major products to be delivered
    and in the objectives of the project, feasible in both technical and business terms?
•   Is the case for the project approach sound and are the risks acceptable?
•   Does management accept what has been included and excluded from the scope?
•   Are all associated systems and their interfaces identified?
•   Is any impact on those systems acceptable?
•   Is the Business Case for the project to proceed valid?




    August 16, 2010                                                                           97
Feasibility Prototype

•   Feasibility prototype may be produced as a proof of
    concept for the proposed solution
      − To prove one or more of the possible technical solutions
        contained within the Feasibility Report
      − To demonstrate to the business the possible content of the user
        interface and the look and feel
•   Prototype should only be produced if it will really assist the
    decisions made in the Feasibility Report




    August 16, 2010                                                       98
Outline Plan for Implementation

•   First planning product within the project
•   Sets deadlines and milestones for various major phases of
    work and key deliverables (particularly incremental
    delivery dates)
•   Deadlines become the major control points around which
    the later, lower level plans will be developed
•   Provides the detailed plan for how the Business Study
    phase will be run




    August 16, 2010                                             99
Outline Plan for Implementation

•   Purpose and objectives
      − Provide management with ballpark estimates of the financial and resource
        implications (both project team and user) of the proposed project
      − Provide a basis for agreement of timescales for the proposed development
        activities
      − Define the high-level acceptance criteria for the proposed deliverables such as
        that the system will conform to all agreed requirements
      − Define and agree the approach to the Business Study phase
      − Identify any particular facilities which the project team will require
      − Define the expected path through the agile framework for the project
      − Identify any currently known issues surrounding the implementation of the
        system and in particular aspects such as data take-on and user handover




    August 16, 2010                                                                       100
Outline Plan for Implementation Questions and
Checklist
•   Are the estimates for effort realistic in the light of the details within the Feasibility
    Report?
•   Are the estimated timescales consistent with the business needs of the project?
•   have the business needs been addressed in terms of what is delivered and when?
•   Is business management able to commit to the level of business resources
    required for the Business Study and to ongoing user involvement for the proposed
    duration of the project?
•   Is development management able to commit to the level of development
    resources required for the Business Study and to ongoing involvement for the
    proposed duration of the project?
•   Will all necessary equipment and facilities be available as required?
•   Is it clear what the criteria for acceptance are and are they rigorous enough to
    define the quality of deliverables while allowing the requirements to flex during
    development?
•   Are all the currently identified standards and guidelines available and for those
    that are not yet available, are there sufficient resources to enable their
    development or procurement?


    August 16, 2010                                                                             101
Phase 3 - Business Study Phase

•   Only initiated if Feasibility Study and Report recommends to proceed with solution
    development
•   Forms the basis for all subsequent work
•   Should be kept as short as possible (weeks rather than months) while achieving
    sufficient understanding of the business requirements and technical constraints to
    move forward with safety
•   Focus is on the business processes affected by the solution and their information
    needs
•   Phase has to be very strongly collaborative using workshops attended by
    knowledgeable staff who can quickly pool their knowledge and gain consensus as
    to the priorities of the development
•   Key workshop output is the Business Area Definition which identifies the business
    processes and associated information and the groups/types of users who will be
    affected in any way by the introduction of the solution
•   Users who will participate in the solution development will be identified and
    agreement reached with their management regarding their involvement

    August 16, 2010                                                                      102
Business Study Phase Outputs

•   Business Area Definition
•   Prioritised Requirements List
•   Development/Implementation Plan
•   System Architecture Definition
•   Updated Solution Risk Log




    August 16, 2010                   103
Business Area Definition

•   Contains a high-level view of the business processes,
    people and information to be supported by the proposed
    solution
•   Evolves into the Functional Model during Functional Model
    Iteration(s)
•   Must be in enough detail to enable both the Development
    Plan and a realistic business case




    August 16, 2010                                             104
Business Area Definition

•   Purpose and Objectives
      − Identify the business needs that should be supported by the
        proposed solution
      − Refine the Outline Business Case (documented in the Feasibility
        Report) to include benefits, risks, costs and impact analyses
      − Outline the information requirements of the business processes
        that will be supported
      − Identify the classes of users impacted by the development and
        introduction of the proposed system
      − Identify the business processes and business scenarios that need
        to change
      − Clarify all interfaces with other systems (human or automated)
      − Verify that the proposed solution is still suitable for development
        using an agile iterative approach

    August 16, 2010                                                           105
Business Area Definition Questions and Checklist

•   Are the business context, business process and business objectives defined and agreed?
•   Have all the currently identified requirements been prioritised (including non-functional
    requirements)?
•   Have all the priorities been assigned in collaboration with the users?
•   Have high-level acceptance criteria for the delivered solution been defined?
•   Are the business areas clearly documented, including high-level information needs that are
    affected by the system?
•   Is the envisaged boundary of the proposed new system realistic in the timescales?
•   Are all classes of users affected by the new system identified?
•   Are the information and processing requirements of the proposed system defined at least
    in outline?
•   Is it still clear that the business needs are being addressed by the proposed new system?
•   Is the person responsible for each business process identified? Can they commit the
    necessary resources and time?
•   Are all major business events (e.g. financial year-end, order received, new supplier taken
    on) identified?




    August 16, 2010                                                                              106
Generating and Managing Requirements

•   All of the requirements identified during the Feasibility and Business
    Studies have to be prioritised and recorded so that the most
    important features will be developed in preference to less essential
    parts that can be added later if required
•   Prioritisation will mainly be led by business need but will also need
    to take into account the technical constraints that may drive some
    requirement to be satisfied first even though it may be less
    important in business terms
•   Some non-functional (operational) requirements, such as security
    and performance, may also affect the prioritisation
•   As parts of the solution will begin to be produced in the next phase
    (the Functional Model Iteration), it is not only important to
    understand the functionality to be developed but also the system
    architecture that will be used

    August 16, 2010                                                          107
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness
Implementing agile iterative project delivery approach and achieving business responsiveness

More Related Content

What's hot

Setting up a Project Management Office (PMO)
Setting up a Project Management Office (PMO)Setting up a Project Management Office (PMO)
Setting up a Project Management Office (PMO)Hussain Bandukwala
 
Meeting For Starting New Project Powerpoint Presentation Slides
Meeting For Starting New Project Powerpoint Presentation SlidesMeeting For Starting New Project Powerpoint Presentation Slides
Meeting For Starting New Project Powerpoint Presentation SlidesSlideTeam
 
A Brief about IT Managed Services
A Brief about IT Managed ServicesA Brief about IT Managed Services
A Brief about IT Managed ServicesFlightcase1
 
Solution design & procurement approach v1
Solution design & procurement approach v1Solution design & procurement approach v1
Solution design & procurement approach v1Doug Walters
 
Managed IT Services Pricing Models And Strategies Powerpoint Presentation Slides
Managed IT Services Pricing Models And Strategies Powerpoint Presentation SlidesManaged IT Services Pricing Models And Strategies Powerpoint Presentation Slides
Managed IT Services Pricing Models And Strategies Powerpoint Presentation SlidesSlideTeam
 
Managed IT Solutions
Managed IT SolutionsManaged IT Solutions
Managed IT SolutionsJohn Maguire
 
Shadow IT And The Failure Of IT Architecture
Shadow IT And The Failure Of IT ArchitectureShadow IT And The Failure Of IT Architecture
Shadow IT And The Failure Of IT ArchitectureAlan McSweeney
 
Ict Vision And Strategy Development
Ict Vision And Strategy DevelopmentIct Vision And Strategy Development
Ict Vision And Strategy DevelopmentAlan McSweeney
 
Establishing an Effective PMO
Establishing an Effective PMOEstablishing an Effective PMO
Establishing an Effective PMOBusiness Beam
 
Governance - Project Management Office Professional Services
Governance - Project Management Office Professional ServicesGovernance - Project Management Office Professional Services
Governance - Project Management Office Professional ServicesMark S. Mahre
 
Managed Services Presentation
Managed Services PresentationManaged Services Presentation
Managed Services PresentationScott Gombar
 
Comprehensive And Integrated Approach To Project Management And Solution Deli...
Comprehensive And Integrated Approach To Project Management And Solution Deli...Comprehensive And Integrated Approach To Project Management And Solution Deli...
Comprehensive And Integrated Approach To Project Management And Solution Deli...Alan McSweeney
 
Trends in the commoditisation of information technology and the need for stra...
Trends in the commoditisation of information technology and the need for stra...Trends in the commoditisation of information technology and the need for stra...
Trends in the commoditisation of information technology and the need for stra...Alan McSweeney
 
MSP Pricing Tips | Determining Optimal Margins for IT Managed Services
MSP Pricing Tips | Determining Optimal Margins for IT Managed ServicesMSP Pricing Tips | Determining Optimal Margins for IT Managed Services
MSP Pricing Tips | Determining Optimal Margins for IT Managed ServicesDavid Castro
 
Manage services presentation
Manage services presentationManage services presentation
Manage services presentationLen Moncrieffe
 
Application Management Services
Application Management ServicesApplication Management Services
Application Management Servicesvenu1506
 
Project Management Office (PMO)
Project Management Office (PMO)Project Management Office (PMO)
Project Management Office (PMO)Anand Subramaniam
 
Comparison and Analysis of Project Management software
Comparison and Analysis of Project Management softwareComparison and Analysis of Project Management software
Comparison and Analysis of Project Management softwareKonstantin Prokhorov, MBA, MSc
 
Project governance
Project governanceProject governance
Project governanceGlen Alleman
 
Integrating It Frameworks, Methodologies And Best Practices Into It Delivery ...
Integrating It Frameworks, Methodologies And Best Practices Into It Delivery ...Integrating It Frameworks, Methodologies And Best Practices Into It Delivery ...
Integrating It Frameworks, Methodologies And Best Practices Into It Delivery ...Alan McSweeney
 

What's hot (20)

Setting up a Project Management Office (PMO)
Setting up a Project Management Office (PMO)Setting up a Project Management Office (PMO)
Setting up a Project Management Office (PMO)
 
Meeting For Starting New Project Powerpoint Presentation Slides
Meeting For Starting New Project Powerpoint Presentation SlidesMeeting For Starting New Project Powerpoint Presentation Slides
Meeting For Starting New Project Powerpoint Presentation Slides
 
A Brief about IT Managed Services
A Brief about IT Managed ServicesA Brief about IT Managed Services
A Brief about IT Managed Services
 
Solution design & procurement approach v1
Solution design & procurement approach v1Solution design & procurement approach v1
Solution design & procurement approach v1
 
Managed IT Services Pricing Models And Strategies Powerpoint Presentation Slides
Managed IT Services Pricing Models And Strategies Powerpoint Presentation SlidesManaged IT Services Pricing Models And Strategies Powerpoint Presentation Slides
Managed IT Services Pricing Models And Strategies Powerpoint Presentation Slides
 
Managed IT Solutions
Managed IT SolutionsManaged IT Solutions
Managed IT Solutions
 
Shadow IT And The Failure Of IT Architecture
Shadow IT And The Failure Of IT ArchitectureShadow IT And The Failure Of IT Architecture
Shadow IT And The Failure Of IT Architecture
 
Ict Vision And Strategy Development
Ict Vision And Strategy DevelopmentIct Vision And Strategy Development
Ict Vision And Strategy Development
 
Establishing an Effective PMO
Establishing an Effective PMOEstablishing an Effective PMO
Establishing an Effective PMO
 
Governance - Project Management Office Professional Services
Governance - Project Management Office Professional ServicesGovernance - Project Management Office Professional Services
Governance - Project Management Office Professional Services
 
Managed Services Presentation
Managed Services PresentationManaged Services Presentation
Managed Services Presentation
 
Comprehensive And Integrated Approach To Project Management And Solution Deli...
Comprehensive And Integrated Approach To Project Management And Solution Deli...Comprehensive And Integrated Approach To Project Management And Solution Deli...
Comprehensive And Integrated Approach To Project Management And Solution Deli...
 
Trends in the commoditisation of information technology and the need for stra...
Trends in the commoditisation of information technology and the need for stra...Trends in the commoditisation of information technology and the need for stra...
Trends in the commoditisation of information technology and the need for stra...
 
MSP Pricing Tips | Determining Optimal Margins for IT Managed Services
MSP Pricing Tips | Determining Optimal Margins for IT Managed ServicesMSP Pricing Tips | Determining Optimal Margins for IT Managed Services
MSP Pricing Tips | Determining Optimal Margins for IT Managed Services
 
Manage services presentation
Manage services presentationManage services presentation
Manage services presentation
 
Application Management Services
Application Management ServicesApplication Management Services
Application Management Services
 
Project Management Office (PMO)
Project Management Office (PMO)Project Management Office (PMO)
Project Management Office (PMO)
 
Comparison and Analysis of Project Management software
Comparison and Analysis of Project Management softwareComparison and Analysis of Project Management software
Comparison and Analysis of Project Management software
 
Project governance
Project governanceProject governance
Project governance
 
Integrating It Frameworks, Methodologies And Best Practices Into It Delivery ...
Integrating It Frameworks, Methodologies And Best Practices Into It Delivery ...Integrating It Frameworks, Methodologies And Best Practices Into It Delivery ...
Integrating It Frameworks, Methodologies And Best Practices Into It Delivery ...
 

Viewers also liked

Cash management configue doc v1
Cash management   configue doc v1Cash management   configue doc v1
Cash management configue doc v1Hari Krishna
 
دورة مكافحة غسل الأموال وتمويل الإرهاب
دورة مكافحة غسل الأموال وتمويل الإرهابدورة مكافحة غسل الأموال وتمويل الإرهاب
دورة مكافحة غسل الأموال وتمويل الإرهابManagerial & Financial Training Centre
 
Lease assets by guntupalliharikrishna
Lease assets by guntupalliharikrishnaLease assets by guntupalliharikrishna
Lease assets by guntupalliharikrishnaHari Krishna
 
Netapp private storage for aws
Netapp private storage for awsNetapp private storage for aws
Netapp private storage for awsMasaru Hiroki
 
SAP Simple Finance Training
SAP Simple Finance TrainingSAP Simple Finance Training
SAP Simple Finance TrainingVenkat reddy
 
Financial and management accounting notes @ mba bk
Financial and management accounting notes @ mba bkFinancial and management accounting notes @ mba bk
Financial and management accounting notes @ mba bkBabasab Patil
 
A project report on customer satisfaction and its impact on sales at rcm mark...
A project report on customer satisfaction and its impact on sales at rcm mark...A project report on customer satisfaction and its impact on sales at rcm mark...
A project report on customer satisfaction and its impact on sales at rcm mark...Babasab Patil
 
VAT configuration for TAXINN
VAT configuration for TAXINNVAT configuration for TAXINN
VAT configuration for TAXINNBvdv Prasad
 
BI-population CMA-ES Algorithms with Surrogate Models and Line Searches
BI-population CMA-ES Algorithms with Surrogate Models and Line SearchesBI-population CMA-ES Algorithms with Surrogate Models and Line Searches
BI-population CMA-ES Algorithms with Surrogate Models and Line SearchesIlya Loshchilov
 
Material ledger by guntupalli hari krishna
Material ledger by guntupalli hari krishnaMaterial ledger by guntupalli hari krishna
Material ledger by guntupalli hari krishnaHari Krishna
 
54627666 ac210-new-gl
54627666 ac210-new-gl54627666 ac210-new-gl
54627666 ac210-new-glmehdi_99
 
SAP FI Asset Accounting: End User Guide for Beginners
SAP FI Asset Accounting: End User Guide for BeginnersSAP FI Asset Accounting: End User Guide for Beginners
SAP FI Asset Accounting: End User Guide for Beginnerssapdocs. info
 
Service taxes india and SAP Configuration (TAXINN)
Service taxes india and SAP Configuration (TAXINN)Service taxes india and SAP Configuration (TAXINN)
Service taxes india and SAP Configuration (TAXINN)Irfan Shokat
 

Viewers also liked (20)

Cash management configue doc v1
Cash management   configue doc v1Cash management   configue doc v1
Cash management configue doc v1
 
دورة مكافحة غسل الأموال وتمويل الإرهاب
دورة مكافحة غسل الأموال وتمويل الإرهابدورة مكافحة غسل الأموال وتمويل الإرهاب
دورة مكافحة غسل الأموال وتمويل الإرهاب
 
Lease assets by guntupalliharikrishna
Lease assets by guntupalliharikrishnaLease assets by guntupalliharikrishna
Lease assets by guntupalliharikrishna
 
Management Accounting
Management AccountingManagement Accounting
Management Accounting
 
Sap mm-end-user-manual
Sap mm-end-user-manualSap mm-end-user-manual
Sap mm-end-user-manual
 
Netapp private storage for aws
Netapp private storage for awsNetapp private storage for aws
Netapp private storage for aws
 
Manufacturer under GST Law
Manufacturer under GST LawManufacturer under GST Law
Manufacturer under GST Law
 
SAP Simple Finance Training
SAP Simple Finance TrainingSAP Simple Finance Training
SAP Simple Finance Training
 
SAP FI-BANK
SAP  FI-BANKSAP  FI-BANK
SAP FI-BANK
 
Financial and management accounting notes @ mba bk
Financial and management accounting notes @ mba bkFinancial and management accounting notes @ mba bk
Financial and management accounting notes @ mba bk
 
A project report on customer satisfaction and its impact on sales at rcm mark...
A project report on customer satisfaction and its impact on sales at rcm mark...A project report on customer satisfaction and its impact on sales at rcm mark...
A project report on customer satisfaction and its impact on sales at rcm mark...
 
VAT configuration for TAXINN
VAT configuration for TAXINNVAT configuration for TAXINN
VAT configuration for TAXINN
 
IDOC
IDOC IDOC
IDOC
 
BI-population CMA-ES Algorithms with Surrogate Models and Line Searches
BI-population CMA-ES Algorithms with Surrogate Models and Line SearchesBI-population CMA-ES Algorithms with Surrogate Models and Line Searches
BI-population CMA-ES Algorithms with Surrogate Models and Line Searches
 
Material ledger by guntupalli hari krishna
Material ledger by guntupalli hari krishnaMaterial ledger by guntupalli hari krishna
Material ledger by guntupalli hari krishna
 
54627666 ac210-new-gl
54627666 ac210-new-gl54627666 ac210-new-gl
54627666 ac210-new-gl
 
SAP FI Asset Accounting: End User Guide for Beginners
SAP FI Asset Accounting: End User Guide for BeginnersSAP FI Asset Accounting: End User Guide for Beginners
SAP FI Asset Accounting: End User Guide for Beginners
 
Foriegn Direct Investments
Foriegn Direct InvestmentsForiegn Direct Investments
Foriegn Direct Investments
 
Certified Management Accountant CMA
Certified Management Accountant   CMACertified Management Accountant   CMA
Certified Management Accountant CMA
 
Service taxes india and SAP Configuration (TAXINN)
Service taxes india and SAP Configuration (TAXINN)Service taxes india and SAP Configuration (TAXINN)
Service taxes india and SAP Configuration (TAXINN)
 

Similar to Implementing agile iterative project delivery approach and achieving business responsiveness

Sgin2013 scrum accomplished-industrialagilecasestudy-avinashrao
Sgin2013 scrum accomplished-industrialagilecasestudy-avinashraoSgin2013 scrum accomplished-industrialagilecasestudy-avinashrao
Sgin2013 scrum accomplished-industrialagilecasestudy-avinashraoIndia Scrum Enthusiasts Community
 
Forming a Project Team
Forming a Project TeamForming a Project Team
Forming a Project TeamMaven
 
ANIn Ahmedabad Feb 2024 | Addressing Challenges in Project Management via Agi...
ANIn Ahmedabad Feb 2024 | Addressing Challenges in Project Management via Agi...ANIn Ahmedabad Feb 2024 | Addressing Challenges in Project Management via Agi...
ANIn Ahmedabad Feb 2024 | Addressing Challenges in Project Management via Agi...AgileNetwork
 
Software engineering by Dr. vishnu sharma
Software engineering by Dr. vishnu sharmaSoftware engineering by Dr. vishnu sharma
Software engineering by Dr. vishnu sharmaVishnu Sharma
 
Introduction to Software Project Management
Introduction to Software Project ManagementIntroduction to Software Project Management
Introduction to Software Project ManagementReetesh Gupta
 
Taking the Creep Out of Scope Creep
Taking the Creep Out of Scope CreepTaking the Creep Out of Scope Creep
Taking the Creep Out of Scope CreepComputer Aid, Inc
 
New Microsoft PowerPoint Presentation (3).pptx
New Microsoft PowerPoint Presentation (3).pptxNew Microsoft PowerPoint Presentation (3).pptx
New Microsoft PowerPoint Presentation (3).pptxPawanNegi39
 
Applying both of waterfall and iterative development
Applying both of waterfall and iterative developmentApplying both of waterfall and iterative development
Applying both of waterfall and iterative developmentDeny Prasetia
 
Scaling Agile - Multiple Team Dynamics
Scaling Agile - Multiple Team DynamicsScaling Agile - Multiple Team Dynamics
Scaling Agile - Multiple Team DynamicsVersionOne
 
Project Management Foundations Series Course 102 - Project Management Processes
Project Management Foundations Series Course 102 - Project Management ProcessesProject Management Foundations Series Course 102 - Project Management Processes
Project Management Foundations Series Course 102 - Project Management ProcessesThink For A Change
 
Pm deep dive integration management
Pm deep dive   integration managementPm deep dive   integration management
Pm deep dive integration managementNiraj Agarwal
 

Similar to Implementing agile iterative project delivery approach and achieving business responsiveness (20)

Ch01
Ch01Ch01
Ch01
 
57086 17 change_control_01
57086 17 change_control_0157086 17 change_control_01
57086 17 change_control_01
 
1. introduction
1. introduction1. introduction
1. introduction
 
Sgin2013 scrum accomplished-industrialagilecasestudy-avinashrao
Sgin2013 scrum accomplished-industrialagilecasestudy-avinashraoSgin2013 scrum accomplished-industrialagilecasestudy-avinashrao
Sgin2013 scrum accomplished-industrialagilecasestudy-avinashrao
 
Forming a Project Team
Forming a Project TeamForming a Project Team
Forming a Project Team
 
ANIn Ahmedabad Feb 2024 | Addressing Challenges in Project Management via Agi...
ANIn Ahmedabad Feb 2024 | Addressing Challenges in Project Management via Agi...ANIn Ahmedabad Feb 2024 | Addressing Challenges in Project Management via Agi...
ANIn Ahmedabad Feb 2024 | Addressing Challenges in Project Management via Agi...
 
Software engineering by Dr. vishnu sharma
Software engineering by Dr. vishnu sharmaSoftware engineering by Dr. vishnu sharma
Software engineering by Dr. vishnu sharma
 
Pe ch 1
Pe ch   1Pe ch   1
Pe ch 1
 
57086 01 introduction
57086 01 introduction57086 01 introduction
57086 01 introduction
 
Introduction to Software Project Management
Introduction to Software Project ManagementIntroduction to Software Project Management
Introduction to Software Project Management
 
Taking the Creep Out of Scope Creep
Taking the Creep Out of Scope CreepTaking the Creep Out of Scope Creep
Taking the Creep Out of Scope Creep
 
New Microsoft PowerPoint Presentation (3).pptx
New Microsoft PowerPoint Presentation (3).pptxNew Microsoft PowerPoint Presentation (3).pptx
New Microsoft PowerPoint Presentation (3).pptx
 
Applying both of waterfall and iterative development
Applying both of waterfall and iterative developmentApplying both of waterfall and iterative development
Applying both of waterfall and iterative development
 
Scaling Agile - Multiple Team Dynamics
Scaling Agile - Multiple Team DynamicsScaling Agile - Multiple Team Dynamics
Scaling Agile - Multiple Team Dynamics
 
Project Management Foundations Series Course 102 - Project Management Processes
Project Management Foundations Series Course 102 - Project Management ProcessesProject Management Foundations Series Course 102 - Project Management Processes
Project Management Foundations Series Course 102 - Project Management Processes
 
Pm deep dive integration management
Pm deep dive   integration managementPm deep dive   integration management
Pm deep dive integration management
 
T349
T349T349
T349
 
T349 Pi Web
T349 Pi WebT349 Pi Web
T349 Pi Web
 
PME UNIT-3.pptx
PME UNIT-3.pptxPME UNIT-3.pptx
PME UNIT-3.pptx
 
Web Project Management
Web Project ManagementWeb Project Management
Web Project Management
 

More from Alan McSweeney

Data Architecture for Solutions.pdf
Data Architecture for Solutions.pdfData Architecture for Solutions.pdf
Data Architecture for Solutions.pdfAlan McSweeney
 
Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...
Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...
Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...Alan McSweeney
 
Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...
Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...
Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...Alan McSweeney
 
IT Architecture’s Role In Solving Technical Debt.pdf
IT Architecture’s Role In Solving Technical Debt.pdfIT Architecture’s Role In Solving Technical Debt.pdf
IT Architecture’s Role In Solving Technical Debt.pdfAlan McSweeney
 
Solution Architecture And Solution Security
Solution Architecture And Solution SecuritySolution Architecture And Solution Security
Solution Architecture And Solution SecurityAlan McSweeney
 
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...Alan McSweeney
 
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...Alan McSweeney
 
Solution Security Architecture
Solution Security ArchitectureSolution Security Architecture
Solution Security ArchitectureAlan McSweeney
 
Solution Architecture And (Robotic) Process Automation Solutions
Solution Architecture And (Robotic) Process Automation SolutionsSolution Architecture And (Robotic) Process Automation Solutions
Solution Architecture And (Robotic) Process Automation SolutionsAlan McSweeney
 
Data Profiling, Data Catalogs and Metadata Harmonisation
Data Profiling, Data Catalogs and Metadata HarmonisationData Profiling, Data Catalogs and Metadata Harmonisation
Data Profiling, Data Catalogs and Metadata HarmonisationAlan McSweeney
 
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...Alan McSweeney
 
Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...
Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...
Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...Alan McSweeney
 
Operational Risk Management Data Validation Architecture
Operational Risk Management Data Validation ArchitectureOperational Risk Management Data Validation Architecture
Operational Risk Management Data Validation ArchitectureAlan McSweeney
 
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...Alan McSweeney
 
Ireland 2019 and 2020 Compared - Individual Charts
Ireland   2019 and 2020 Compared - Individual ChartsIreland   2019 and 2020 Compared - Individual Charts
Ireland 2019 and 2020 Compared - Individual ChartsAlan McSweeney
 
Analysis of Irish Mortality Using Public Data Sources 2014-2020
Analysis of Irish Mortality Using Public Data Sources 2014-2020Analysis of Irish Mortality Using Public Data Sources 2014-2020
Analysis of Irish Mortality Using Public Data Sources 2014-2020Alan McSweeney
 
Ireland – 2019 And 2020 Compared In Data
Ireland – 2019 And 2020 Compared In DataIreland – 2019 And 2020 Compared In Data
Ireland – 2019 And 2020 Compared In DataAlan McSweeney
 
Review of Information Technology Function Critical Capability Models
Review of Information Technology Function Critical Capability ModelsReview of Information Technology Function Critical Capability Models
Review of Information Technology Function Critical Capability ModelsAlan McSweeney
 
Critical Review of Open Group IT4IT Reference Architecture
Critical Review of Open Group IT4IT Reference ArchitectureCritical Review of Open Group IT4IT Reference Architecture
Critical Review of Open Group IT4IT Reference ArchitectureAlan McSweeney
 
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020Alan McSweeney
 

More from Alan McSweeney (20)

Data Architecture for Solutions.pdf
Data Architecture for Solutions.pdfData Architecture for Solutions.pdf
Data Architecture for Solutions.pdf
 
Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...
Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...
Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...
 
Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...
Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...
Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...
 
IT Architecture’s Role In Solving Technical Debt.pdf
IT Architecture’s Role In Solving Technical Debt.pdfIT Architecture’s Role In Solving Technical Debt.pdf
IT Architecture’s Role In Solving Technical Debt.pdf
 
Solution Architecture And Solution Security
Solution Architecture And Solution SecuritySolution Architecture And Solution Security
Solution Architecture And Solution Security
 
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
 
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
 
Solution Security Architecture
Solution Security ArchitectureSolution Security Architecture
Solution Security Architecture
 
Solution Architecture And (Robotic) Process Automation Solutions
Solution Architecture And (Robotic) Process Automation SolutionsSolution Architecture And (Robotic) Process Automation Solutions
Solution Architecture And (Robotic) Process Automation Solutions
 
Data Profiling, Data Catalogs and Metadata Harmonisation
Data Profiling, Data Catalogs and Metadata HarmonisationData Profiling, Data Catalogs and Metadata Harmonisation
Data Profiling, Data Catalogs and Metadata Harmonisation
 
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...
 
Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...
Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...
Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...
 
Operational Risk Management Data Validation Architecture
Operational Risk Management Data Validation ArchitectureOperational Risk Management Data Validation Architecture
Operational Risk Management Data Validation Architecture
 
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...
 
Ireland 2019 and 2020 Compared - Individual Charts
Ireland   2019 and 2020 Compared - Individual ChartsIreland   2019 and 2020 Compared - Individual Charts
Ireland 2019 and 2020 Compared - Individual Charts
 
Analysis of Irish Mortality Using Public Data Sources 2014-2020
Analysis of Irish Mortality Using Public Data Sources 2014-2020Analysis of Irish Mortality Using Public Data Sources 2014-2020
Analysis of Irish Mortality Using Public Data Sources 2014-2020
 
Ireland – 2019 And 2020 Compared In Data
Ireland – 2019 And 2020 Compared In DataIreland – 2019 And 2020 Compared In Data
Ireland – 2019 And 2020 Compared In Data
 
Review of Information Technology Function Critical Capability Models
Review of Information Technology Function Critical Capability ModelsReview of Information Technology Function Critical Capability Models
Review of Information Technology Function Critical Capability Models
 
Critical Review of Open Group IT4IT Reference Architecture
Critical Review of Open Group IT4IT Reference ArchitectureCritical Review of Open Group IT4IT Reference Architecture
Critical Review of Open Group IT4IT Reference Architecture
 
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020
 

Recently uploaded

Keep Your Finger on the Pulse of Your Building's Performance with IES Live
Keep Your Finger on the Pulse of Your Building's Performance with IES LiveKeep Your Finger on the Pulse of Your Building's Performance with IES Live
Keep Your Finger on the Pulse of Your Building's Performance with IES LiveIES VE
 
.NET 8 ChatBot with Azure OpenAI Services.pptx
.NET 8 ChatBot with Azure OpenAI Services.pptx.NET 8 ChatBot with Azure OpenAI Services.pptx
.NET 8 ChatBot with Azure OpenAI Services.pptxHansamali Gamage
 
My key hands-on projects in Quantum, and QAI
My key hands-on projects in Quantum, and QAIMy key hands-on projects in Quantum, and QAI
My key hands-on projects in Quantum, and QAIVijayananda Mohire
 
How to become a GDSC Lead GDSC MI AOE.pptx
How to become a GDSC Lead GDSC MI AOE.pptxHow to become a GDSC Lead GDSC MI AOE.pptx
How to become a GDSC Lead GDSC MI AOE.pptxKaustubhBhavsar6
 
Stobox 4: Revolutionizing Investment in Real-World Assets Through Tokenization
Stobox 4: Revolutionizing Investment in Real-World Assets Through TokenizationStobox 4: Revolutionizing Investment in Real-World Assets Through Tokenization
Stobox 4: Revolutionizing Investment in Real-World Assets Through TokenizationStobox
 
Webinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - Tech
Webinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - TechWebinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - Tech
Webinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - TechProduct School
 
IT Service Management (ITSM) Best Practices for Advanced Computing
IT Service Management (ITSM) Best Practices for Advanced ComputingIT Service Management (ITSM) Best Practices for Advanced Computing
IT Service Management (ITSM) Best Practices for Advanced ComputingMAGNIntelligence
 
The Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and InsightThe Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and InsightSafe Software
 
Where developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is goingWhere developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is goingFrancesco Corti
 
March Patch Tuesday
March Patch TuesdayMarch Patch Tuesday
March Patch TuesdayIvanti
 
Patch notes explaining DISARM Version 1.4 update
Patch notes explaining DISARM Version 1.4 updatePatch notes explaining DISARM Version 1.4 update
Patch notes explaining DISARM Version 1.4 updateadam112203
 
Novo Nordisk's journey in developing an open-source application on Neo4j
Novo Nordisk's journey in developing an open-source application on Neo4jNovo Nordisk's journey in developing an open-source application on Neo4j
Novo Nordisk's journey in developing an open-source application on Neo4jNeo4j
 
UiPath Studio Web workshop series - Day 2
UiPath Studio Web workshop series - Day 2UiPath Studio Web workshop series - Day 2
UiPath Studio Web workshop series - Day 2DianaGray10
 
20140402 - Smart house demo kit
20140402 - Smart house demo kit20140402 - Smart house demo kit
20140402 - Smart house demo kitJamie (Taka) Wang
 
The Importance of Indoor Air Quality (English)
The Importance of Indoor Air Quality (English)The Importance of Indoor Air Quality (English)
The Importance of Indoor Air Quality (English)IES VE
 
TrustArc Webinar - How to Live in a Post Third-Party Cookie World
TrustArc Webinar - How to Live in a Post Third-Party Cookie WorldTrustArc Webinar - How to Live in a Post Third-Party Cookie World
TrustArc Webinar - How to Live in a Post Third-Party Cookie WorldTrustArc
 
EMEA What is ThousandEyes? Webinar
EMEA What is ThousandEyes? WebinarEMEA What is ThousandEyes? Webinar
EMEA What is ThousandEyes? WebinarThousandEyes
 
Flow Control | Block Size | ST Min | First Frame
Flow Control | Block Size | ST Min | First FrameFlow Control | Block Size | ST Min | First Frame
Flow Control | Block Size | ST Min | First FrameKapil Thakar
 
Oracle Database 23c Security New Features.pptx
Oracle Database 23c Security New Features.pptxOracle Database 23c Security New Features.pptx
Oracle Database 23c Security New Features.pptxSatishbabu Gunukula
 
Technical SEO for Improved Accessibility WTS FEST
Technical SEO for Improved Accessibility  WTS FESTTechnical SEO for Improved Accessibility  WTS FEST
Technical SEO for Improved Accessibility WTS FESTBillieHyde
 

Recently uploaded (20)

Keep Your Finger on the Pulse of Your Building's Performance with IES Live
Keep Your Finger on the Pulse of Your Building's Performance with IES LiveKeep Your Finger on the Pulse of Your Building's Performance with IES Live
Keep Your Finger on the Pulse of Your Building's Performance with IES Live
 
.NET 8 ChatBot with Azure OpenAI Services.pptx
.NET 8 ChatBot with Azure OpenAI Services.pptx.NET 8 ChatBot with Azure OpenAI Services.pptx
.NET 8 ChatBot with Azure OpenAI Services.pptx
 
My key hands-on projects in Quantum, and QAI
My key hands-on projects in Quantum, and QAIMy key hands-on projects in Quantum, and QAI
My key hands-on projects in Quantum, and QAI
 
How to become a GDSC Lead GDSC MI AOE.pptx
How to become a GDSC Lead GDSC MI AOE.pptxHow to become a GDSC Lead GDSC MI AOE.pptx
How to become a GDSC Lead GDSC MI AOE.pptx
 
Stobox 4: Revolutionizing Investment in Real-World Assets Through Tokenization
Stobox 4: Revolutionizing Investment in Real-World Assets Through TokenizationStobox 4: Revolutionizing Investment in Real-World Assets Through Tokenization
Stobox 4: Revolutionizing Investment in Real-World Assets Through Tokenization
 
Webinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - Tech
Webinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - TechWebinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - Tech
Webinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - Tech
 
IT Service Management (ITSM) Best Practices for Advanced Computing
IT Service Management (ITSM) Best Practices for Advanced ComputingIT Service Management (ITSM) Best Practices for Advanced Computing
IT Service Management (ITSM) Best Practices for Advanced Computing
 
The Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and InsightThe Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and Insight
 
Where developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is goingWhere developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is going
 
March Patch Tuesday
March Patch TuesdayMarch Patch Tuesday
March Patch Tuesday
 
Patch notes explaining DISARM Version 1.4 update
Patch notes explaining DISARM Version 1.4 updatePatch notes explaining DISARM Version 1.4 update
Patch notes explaining DISARM Version 1.4 update
 
Novo Nordisk's journey in developing an open-source application on Neo4j
Novo Nordisk's journey in developing an open-source application on Neo4jNovo Nordisk's journey in developing an open-source application on Neo4j
Novo Nordisk's journey in developing an open-source application on Neo4j
 
UiPath Studio Web workshop series - Day 2
UiPath Studio Web workshop series - Day 2UiPath Studio Web workshop series - Day 2
UiPath Studio Web workshop series - Day 2
 
20140402 - Smart house demo kit
20140402 - Smart house demo kit20140402 - Smart house demo kit
20140402 - Smart house demo kit
 
The Importance of Indoor Air Quality (English)
The Importance of Indoor Air Quality (English)The Importance of Indoor Air Quality (English)
The Importance of Indoor Air Quality (English)
 
TrustArc Webinar - How to Live in a Post Third-Party Cookie World
TrustArc Webinar - How to Live in a Post Third-Party Cookie WorldTrustArc Webinar - How to Live in a Post Third-Party Cookie World
TrustArc Webinar - How to Live in a Post Third-Party Cookie World
 
EMEA What is ThousandEyes? Webinar
EMEA What is ThousandEyes? WebinarEMEA What is ThousandEyes? Webinar
EMEA What is ThousandEyes? Webinar
 
Flow Control | Block Size | ST Min | First Frame
Flow Control | Block Size | ST Min | First FrameFlow Control | Block Size | ST Min | First Frame
Flow Control | Block Size | ST Min | First Frame
 
Oracle Database 23c Security New Features.pptx
Oracle Database 23c Security New Features.pptxOracle Database 23c Security New Features.pptx
Oracle Database 23c Security New Features.pptx
 
Technical SEO for Improved Accessibility WTS FEST
Technical SEO for Improved Accessibility  WTS FESTTechnical SEO for Improved Accessibility  WTS FEST
Technical SEO for Improved Accessibility WTS FEST
 

Implementing agile iterative project delivery approach and achieving business responsiveness

  • 1. Implementing Agile Iterative Project Delivery Approach and Achieving Business Responsiveness Alan McSweeney
  • 2. Objectives • To describe a generalised agile and iterative approach to information technology projects and the use of the agile approach within organisations August 16, 2010 2
  • 3. Agenda • Introduction • Agile Iterative Approach to Projects − Using Agile Effectively and Productively − Control Components of Agile Process − Agile Tools and Techniques − Iterative Agile Framework and Phases • Using Agile Iterative Approach for Specific Projects • Introducing Agile Iterative Approach into an Organisation August 16, 2010 3
  • 5. Projects • Projects are about change − New or changes to existing processes, systems, applications, structures • Organisations need to be good at two sets of skills − Running the Business (RTB) – business as usual operations − Change the Business (CTB) – changing existing operations to survive or compete • Projects are the way of introducing change into organisations • Projects tend to be multidisciplinary, involving some or all of: − Requirements gathering − Solution design − Hardware installation − Product selection − Software development or modification − Testing − Process change − Organisation change − Data conversion − Implementation − Parallel operation • Organisations need to be good at projects in order to deliver change August 16, 2010 5
  • 6. Dimensions of Being Good At Organisational Change Ability to • To be good at change, three Execute Projects dimensions must come together within the organisation: − A clear vision for the organisation and the set of projects needed to deliver on the vision − A proven capability to deliver projects quickly and effectively Completeness of Organisational − Focus on the realisation of Vision expected business benefits and business value associated with the implementation of information technology investments • Agile approach to projects is one way of being good at Effective and Proven change Benefits Realisation Approach August 16, 2010 6
  • 7. Projects Fail • Yes – projects fail – it’s no surprise • Fail occurs largely because of people rather than technology issues • Project success means the project delivered on time, on budget, to agreed specification and delivering the agreed business benefits • Different types and scales of project failure − Delivered solution fails to meet the business requirements for which it was implemented and its use is abandoned or expensive adjustments are made − There are performance problems in the delivered solution which means it is insufficient to meet the needs of users and its use is abandoned or expensive adjustments are made − After implementation errors and gaps appear in the delivered solution causing unexpected problem and its use is abandoned or expensive adjustments are made − Users reject, bypass or circumvent the delivered solution because of lack of consultation, involvement, commitment, agreement or other reasons − Delivered solution is used but over gradually become to expensive or complex to maintain and falls into disuse − Project is late and/or over budget − Project does not deliver the business benefits August 16, 2010 7
  • 8. Spectrum of Project Failures More Expensive Functionality Delivered to Operate Than Does not Meet Business Planned Requirements Specified Business Benefits and Savings Not Project Late Delivered Significant and/or Over Rework Budget Required Complete Complete Success Failure Performance and/or Operational Solution Problems Largely Unused Complete Project Complete Project Success: Failure: Cancelled, On-time, On-budget Unused, Rejected August 16, 2010 8
  • 9. Balancing Solution Functionality and Implementation Project Cost/Resources and Time • Traditional view of projects is that they are a balance between meeting requirements (solution functionality), implementation project resources (and thus cost) and project time • Functionality (requirements) is fixed and cost and time must vary August 16, 2010 9
  • 10. Balancing Solution Functionality and Implementation Project Cost/Resources and • Resources are constrained so • Time is constrained so project time must increase resources must increase August 16, 2010 10
  • 11. Project Risk/Quality Factor • Reality is that all projects have a risk dimension – projects fail all too frequently • Risk and quality are interrelated • Risk increases with project duration, size of project team and complexity of solution being implemented August 16, 2010 11
  • 12. Projects and Changes • Organisations need to deliver projects to business in shorter timescales in response to internal and external • Project processes need to be flexible, responsive and agile in order to deliver what the organisation needs when it needs it • Traditionally projects are delivered in a series of sequential phases designed to create certainty around the solution being delivered − Gather requirements − Design solution − Technical and detailed design − Development/modification − Testing − Implementation − Operation • Sequential approach has disadvantages − Not sufficiently flexible to accommodate changes in requirements − Resources are wasted building features that nobody needs − Opportunity to provide feedback limited until a large part of the solution is delivered − Solution stability and operability not certain until late in the project August 16, 2010 12
  • 13. What Makes Projects Succeed • User involvement and commitment • Executive management sponsorship • Defined and certain business objectives • Defined and agreed requirements • Defined scope • Flexible and reactive delivery process • Project management skill and experience • Good control of project costs • Skilled and experienced project team • Project delivery methodology • Proven technology August 16, 2010 13
  • 14. What Makes Projects Fail • Lack of or changing executive • Unclear definition of roles and management commitment responsibilities • Unclear of scope, objectives and • Artificial and unrealistic deadlines requirements • Specifications not agreed • Lack of user commitment and • New or radically redesigned involvement underlying business processes • Changing scope and objectives and • Use of new technology poor change control • Poor planning and estimation • Poor project control against targets • Poor project management • Large number of organisational units involved • Failure to manage end-user • Lack of effective project expectations methodologies • Lack of agreement between • High project staff turnover stakeholders • Lack of skills and experience in the project team August 16, 2010 14
  • 15. Flexible, Responsive, Agile Project Approach • An agile approach to project delivery seeks to reduce risks associated with sequential solution delivery approach − Multiple iterations/releases − Sets of smaller deliveries − Prioritised requirements − Greater user involvement − Lower overall cost • Agile approach tends to be good for projects with inherent uncertainty and volatility − Transformation and organisational change projects − Support and maintenance − Research and development − Information technology August 16, 2010 15
  • 16. Applying Agile Approach to Projects • Agile approach tends to be associated with software development projects • More general approach and can and should be applied more widely to other projects (that may have a development component) August 16, 2010 16
  • 17. Classification of Projects Highly Here be Undefined Dragons and Far from Agreement Project Requirements Highly Complex Complicated Difficult Well Defined/ Simple Agreed Project Technology Well Highly Proven Uncertain August 16, 2010 17
  • 18. Solution Functionality Used • Most of the functionality of delivered solutions is never or seldom used − Not surprising – think of all the features in applications such as Microsoft Office − How much do you use? • Represents a significant cost • Tendency is always to deliver complex feature-rich solutions • Simplicity is not seen as good August 16, 2010 18
  • 19. Agile Iterative Approach to Projects • Time is fixed for the life of a project and resources are fixed as far as possible • Requirements that will be satisfied are allowed to change • Flexibility of requirements to be satisfied has significant impact on the development processes and controls, and on acceptance of the system • Iterative approach reduces risk by continuously reaffirming and validating the solution being implemented August 16, 2010 19
  • 20. Agile Iterative Approach to Projects August 16, 2010 20
  • 21. What is Meant by Agility • Driven by user descriptions/scenarios of what is required of the solution • Seeks constant user feedback • Recognises that plans are short-lived • Develops solution iteratively with a emphasis on development activities • Delivers multiple working solution increments • Adapts as changes occur August 16, 2010 21
  • 22. What Are the Potential Issues With Agile Approach • May not apply to large and complex projects • May not be suitable to all organisations and people • Delivered solutions may not be scalable to large volumes of users/transactions/workload/data • Delivered solutions may not be adaptable to meet future business needs August 16, 2010 22
  • 23. Agile and People • People are at the core of an agile process • The process adapts to the needs of the team needs rather than imposing a structure on the team as with conventional sequential processes • An effective agile team should be: − Competent − Working towards a common goal − Collaborative − Able to make decisions − Good at solving problems − Trust and respect one another − Self-organising with respect to workload, schedule and project processes August 16, 2010 23
  • 24. Iterative Agile Approach to Projects • Fundamental assumption of agile approach to projects is that nothing is built perfectly first time • 80% of the solution can be implemented in 20% of the time that it would take to produce the total solution • All deliverables from previous project steps can potentially be revisited as part of the iterative approach • Only enough of the current step need be completed to move to the next step • Designed to address the current and immediate needs of the business • Deliver simpler solutions more quickly that are fit for purpose and easier to maintain and modify after their initial implementation August 16, 2010 24
  • 25. Agile Approach to Ensuring Project Success • Satisfies the real requirements of the organisation prioritised by importance • Supports the way the organisation needs to work • Aims to deliver quality solution on time and within budget • Aims to deliver quickly and effectively − Required functionality, performance, security, operability and maintainability August 16, 2010 25
  • 26. Using Agile Iterative Approach • All too frequently seen as a panacea to project problems − It is not − Agile is hard • Agile has become fashionable without an understanding of the effort involved • Agile requires commitment, involvement and can be intense and demanding • If you have current project problems, agile is probably not the solution − You need to fix the underlying organisational issues first August 16, 2010 26
  • 27. Agile Approaches • Lots of different agile approaches − Adaptive Software Development (ASD) − Agile Unified Process (AUP) − Crystal Clear − DSDM (Dynamic Systems Development Method) − Essential Unified Process (EssUP) − FDD (Feature Driven Development) − Incremental SDLC − Open Unified Process (OpenUP) − RAD (Rapid Application Development) − Scrum − Spiral SDLC − TDD (Test-driven development) − XP (Extreme programming) • Common features − Teamwork, collaboration, and process flexibility adaptability throughout the project lifecycle − Divide tasks into smaller increments with accelerated planning − Multiple small iterations • Many agile processes are focussed on software development projects • Need a more generalised agile approach that can be applied to all information technology projects August 16, 2010 27
  • 28. Benefits of Iterative Agile Approach to Solution Delivery • Users are more likely to be committed to the solution • Risk of building the wrong solution is substantially reduced • Final system is more likely to meet the real needs of the organisation • Implementation is more likely to be easier because of the involvement of all parties concerned throughout the project August 16, 2010 28
  • 29. Agile Iterative Approach Structure Generalised Approach to Agile Iterative Projects Project Selection and Control Components of Agile Tools and Agile Phases Validation Agile Process Techniques Agile Approach Timeboxing Workshops Pre-Project Suitability Checklist Solutions and Projects MoSCoW Prioritisation Feasibility Analysis and Models and Modelling When to Use Agile of Requirements Study Agile Project Critical Business Analysis and Estimation Prototypes Success Factors Study Key Principles of Project Management Functional Model Testing Iterative Agile Approach and Project Planning Iteration Configuration Design and Build Risk Management Management Iteration Quality Management Implementation Measurement Post-Project August 16, 2010 29
  • 30. Using Agile Effectively and Productively Agile Approach Solutions and Suitability Projects When Checklist to Use Agile Agile Project Key Principles Critical Success of Iterative Factors Agile Approach August 16, 2010 30
  • 31. Checklist of Suitability of Projects for Agile Iterative Approach • Do the sponsor and management understand and accept the agile philosophy as their buy-in is essential? • Will the team members be empowered to make decisions? • Is there senior user commitment to provide end user involvement? • Can the organisation accommodate the frequent delivery of increments? • Will it be possible for the project team to have access to the users throughout the project? • Will the project team remain the same throughout the project as stability of the team including the user representatives is important? • Will the project team have the appropriate skills including technical skills, knowledge of the business area? • Will the individual project teams consist of six people or less? • Will the project use technology suitable for prototyping? • Is there a highly demonstrable user interface? • Is there clear ownership? • Will the solution development be computationally non-complex as the more complex the development the greater the risks involved? • Can the solution be implemented in increments if required? • Has the development a fixed timescale? • Can the requirements be prioritised with a mix of Must Haves, Should Haves, Could Haves and Want to Have but Won't Have This Time? • Are the requirements not too detailed and fixed so users can define requirements interactively? August 16, 2010 31
  • 32. Solutions and Projects When to Use Agile • Solution that is interactive, where the functionality is clearly demonstrable at the user interface − Agile is based on incremental prototyping with close user involvement − User must be able to assess the functionality easily through viewing and operating working prototypes • Solution that has a clearly defined user group − If the user group is not clearly defined, there may be a danger of driving the solution from a wrong viewpoint or ignoring some important aspect of the project entirely • Solution that is computationally complex, the complexity can be decomposed or isolated − If the internals of the solution are hard to understand via the user interface then there is a risk − Level of computational complexity is often quite difficult to determine in advance − Interactions between different components that can be difficult to identify up front August 16, 2010 32
  • 33. Solutions and Projects When to Use Agile • Solution that is large, possesses the capability of being split into smaller functional components − If the proposed solution is large it should be possible to break it down into small, manageable chunks, each delivering some clear functionality − These can then be delivered sequentially or in parallel − Each sub-project must be constantly aware of the overall system architecture • Solution that is time-constrained − There should be a fixed end date by which the project must be completed − If there is no real case for the end date to be fixed, it will be relatively easy to allow schedules to slip and the fundamental benefits of agile approach will be lost • Solution where requirements can be prioritised − Requirements should be able to be prioritised using the MoSCoW rules • Solution where requirements are unclear or subject to frequent change − In periods of rapid change it may be difficult to specify the requirements in detail at the outset of the project making traditional approaches unsuitable − Agile approach is designed specifically to deal with requirements that change and evolve during a project − Applications that are difficult to specify in advance because the users do not know exactly what is needed at the outset August 16, 2010 33
  • 34. Solutions and Projects When Not to Use Agile • Process control/real-time applications • Requirements that have to be fully specified before any programs are written • Safety-critical applications • Solutions aimed at delivering re-usable components August 16, 2010 34
  • 35. Agile Project Critical Success Factors • Acceptance of the agile approach before starting work • Delegation of decision-making to the business people and developers in the development team • Commitment of senior business management to provide significant end-user involvement • Incremental delivery • Easy access by developers to end-users • Stability of the team • Project team should be highly skilled people in terms of both the business area as well as the technical environment • Size of the project team should be small in order to minimise the overheads of management and communication • Solution technology that allows iterative development, demonstrable work products and control of versions August 16, 2010 35
  • 36. Key Principles of Iterative Agile Approach • Iterative agile approach requires acceptance of key principles 1. Active user involvement is essential 2. Collaborative and co-operative approach between all stakeholders is essential 3. Agile project team must be allowed make decisions 4. Focus is on frequent delivery of products 5. Fitness for business purpose is the essential measure for acceptance of deliverables 6. Iterative and incremental development is necessary to converge on an accurate business solution 7. All changes during solution implementation are reversible 8. Requirements are baselined at a high level 9. Testing is integrated and performed throughout the lifecycle August 16, 2010 36
  • 37. Principle 1 - Active User Involvement is Essential • Agile is user-centered • If users are not closely involved throughout the project lifecycle, delays will occur during decisions making • Users may feel that the final solution is imposed by the project team and/or their own management • Users are not outside the project team acting as suppliers of information and reviewers of results but are active participants in the project process • User and thus business commitment is fundamental to success August 16, 2010 37
  • 38. Principle 2 - Collaborative and Co-operative Approach Between All Stakeholders is Essential • The nature of agile projects means that low-level detailed requirements are not necessarily fixed when the team is assembled to perform the work • The short-term direction that a project takes must be quickly decided without the use of restrictive change control procedures • The stakeholders include not only the business and development staff within the project, but also other staff such as service delivery and resource managers • When development is procured from an external supplier, both the vendor and the purchaser organisations should aim for as efficient a process as possible while allowing for flexibility during both the pre- contract phase and when the contracted work is carried out − Can be difficult and needs substantial mutual trust August 16, 2010 38
  • 39. Principle 3 - Agile Project Team Must Be Allowed Make Decisions • Project teams must be mixed and consist of both IT personnel and users • Project teams must be able to make decisions as requirements are refined and possibly changed • Project teams must be able to agree that defined levels of functionality, usability, etc. are acceptable without frequent need to refer to higher-level management August 16, 2010 39
  • 40. Principle 4 - Focus is on Frequent Delivery of Products • A product-based approach is more flexible than an activity- based one − Products include interim development products, not just delivered solutions • Work of a project team is concentrated on products that can be delivered in an agreed period of time • Enables the team to select the best approach to achieving the products required in the time available • By keeping each period of time short, the team can easily decide which activities are necessary and sufficient to achieve the right products August 16, 2010 40
  • 41. Principle 5 - Fitness for Business Purpose is the Essential Measure for Acceptance of Deliverables • Focus of agile is on delivering the necessary functionality at the required time • Traditional project focus has been on satisfying the contents of a requirements document and conforming to previous deliverables, even though the requirements are often inaccurate, the previous deliverables may be flawed and the business needs may have changed since the start of the project • Solution can be more rigorously engineered subsequently if such an approach is acceptable August 16, 2010 41
  • 42. Principle 6 - Iterative and Incremental Development is Necessary to Converge on an Accurate Business Solution • Agile iterative approach allows systems to grow incrementally • Therefore the project team can make full use of feedback from the users • Partial solutions can be delivered to satisfy immediate business needs • Agile approach uses iteration to continuously improve the solution being implemented • When rework is not explicitly recognised in a project lifecycle, the return to previously "completed" work is surrounded by controlling procedures that slow development down • Rework is built into the agile iterative approach process, the solution can proceed more quickly during iteration August 16, 2010 42
  • 43. Principle 7 - All Changes During Solution Implementation are Reversible • To control the evolution of all products (documents, software, test products, etc.), everything must be in a known state at all times − Configuration management must be all-pervasive • Backtracking is a feature of agile iterative approach − Sometimes it may be easier to reconstruct than to backtrack depending on the nature of the change and the environment in which it was made August 16, 2010 43
  • 44. Principle 8 - Requirements are Baselined at a High Level • Baselining high-level requirements involves "freezing" and agreeing the purpose and scope of the system at a level that allows for detailed investigation of what the requirements imply • Further, more detailed baselines can be established later in the project − The scope should not change significantly • Changing the scope defined in the baselined high-level requirements generally requires escalation August 16, 2010 44
  • 45. Principle 9 - Testing is Integrated and Performed Throughout the Lifecycle • Testing is not treated as a separate activity • As the solution is developed incrementally, it is also tested and reviewed by both the project team and users incrementally − Ensures that the project is moving forward not only in the right business direction but is also technically sound • Early in project lifecycle, the testing focus is on validation against the business needs and priorities • Towards the end of the project, the focus is on verifying that the whole system operates effectively – system and integration testing August 16, 2010 45
  • 46. Control Components of Agile Process • Since agile iterative projects are flexible in their development activities all aspects of their management need to be flexible while maintaining a level of control that ensures successful delivery of the required business solution • Key control techniques and components − Timeboxing − MoSCoW prioritisation of requirements − Estimation − Project management and project planning − Risk management − Configuration management − Measurement August 16, 2010 46
  • 47. Timeboxing • Very important aspect of agile iterative process and projects • Process to reach defined objectives at a pre-determined and fixed date through continuous prioritisation and flexing of requirements using the MoSCoW control rule • Timebox is a fixed interval of time - typically between two and six weeks in length but the shorter the better • Without the control of timeboxing, project teams can lose their focus and run out of control • Used at various stages of project − Project end-date is fixed and the overall business objectives to be achieved by that date are defined − End date for each increment within the project is fixed and the prioritised set of business and technical requirements to be satisfied by that date are defined − End date for phase level activities is fixed, e.g. for the Feasibility Study, and the objectives for this project defined − End date for part of the prototyping activity is fixed and the prototype is created, reviewed and tested according to the objectives defined in the timebox schedule contained in the Development Plan − End time for a workshop, meeting or review is fixed and the participants work to the predefined and prioritised objectives August 16, 2010 47
  • 48. Timeboxing • A timebox must have an agreed scope and clear objectives based on a subset of the prioritised requirements list • With timeboxing control is not activity-based • Objective of a timebox is to make a product - produce something tangible in order for progress and quality to be assessed • How that product is put together will be decided by the people doing the work, as long as the project's standards and procedures are followed • Team working in the timebox must agree the objectives and must themselves estimate the time required • At the deadline, the users must be able to approve the delivery of the products covered by the timebox • If it appears that deadlines could be missed, the deliverable should be de-scoped dropping the lower priority items • Detailed planning of a subsequent timebox containing dependent work cannot be started before the current timebox is complete August 16, 2010 48
  • 49. Timebox Plan • Plan for an individual timebox within Functional Model and Design and Build Iteration phase • Purpose and objectives • Define the products of an individual timebox • Define key milestones, e.g. technical or user review dates, within a timebox • Agree the prioritisation of products and activities within a timebox August 16, 2010 49
  • 50. Timeboxing and Daily Meetings • During each timebox, the team working on the timebox should meet daily to review their progress and to raise issues − Provides the team with evidence regarding their progress and the problems they face − Highlight risks as they occur − Each daily meeting should be limited at 30 minutes and ideally lasts no longer than 15 minutes − All team members attend • Agenda − What work has been completed for this timebox since the last daily meeting? − What (if anything) got in the way of completing the planned work? − What work will be done between now and the next daily meeting? August 16, 2010 50
  • 51. Timebox Plan Questions and Checklist • Are the estimates of effort reasonable? Were they produced by the people doing the work? • Have acceptance criteria been agreed for the products of the timebox? If they have not, is it clear when these will be available? • Is there a high degree of certainty that the Must Haves will be created, developed and tested to the required standard? • Are the review dates agreed with all key personnel? • Have lessons learnt in previous timeboxes been applied? • Can the team commit to delivering at least the Must Haves by the agreed end date? August 16, 2010 51
  • 52. MoSCoW Prioritisation of Requirements • MoSCoW − Must Have • Requirements that are fundamental to the system • Without them the system will be unworkable and useless • Must Haves define the minimum usable subset • Agile project guarantees to satisfy all the minimum usable subset − Should Have • Important requirements for which there is a workaround in the short term and which would normally be classed as mandatory in less time-constrained development, but the system will be useful and usable without them − Could Have • Requirements that can more easily be left out of the increment under development − Want to Have but Won't Have This Time • Requirements that can wait till later development takes place - the Waiting List August 16, 2010 52
  • 53. MoSCoW Prioritisation of Requirements • Delivering on a guaranteed date means that what was originally envisaged for an individual delivery may have to be left out • Important that essential work is done and that only less critical work is omitted • Means of ensuring that this is true is clear prioritisation of the requirements • Provides a basis on which decisions are made about what the project team will do over the whole project, within an increment of the project and during a timebox within an increment • As new requirements arise or as existing requirements are defined in more detail, the decision must be made as to how critical they are to the success of the current work using the MoSCoW approach − All priorities should be reviewed throughout the project to ensure that they are still valid • Essential that not everything to be achieved within a project or a timebox is a Must Have − Having lower level requirements that enable teams to deliver on time by dropping out lower priority requirements when problems arise August 16, 2010 53
  • 54. MoSCoW Prioritisation of Requirements • Solution functionality is prioritised and delivered according to available time and resources but time and resources are fixed August 16, 2010 54
  • 55. Estimation • Estimation provides the information that is required for two main purposes: − Assess project feasibility by evaluating costs and benefits − Use in project planning, scheduling and control • Estimation in agile iterative projects − Estimates should be tight from the outset with frequent deliverables • Not unacceptable for activity overrun and for long timescales for agreeing the quality of products − Estimates that are based on outline business functions provide the closest match with the agile iterative process • Starting point for estimating should be the expected functionality of the end products rather than the activities used to deliver those products August 16, 2010 55
  • 56. Estimation • Estimation is a conditional forecast based on the information available at the time − An extrapolation from past and current knowledge to the future − Cannot be done with complete certainty because the future is unknown, therefore the actual effort or cost to deliver will almost always be different to the estimate − Better the quality of the information available for estimating, the closer the estimate is likely to be to the actual figures • Estimation must be based on a defined process so that it is rigorous and repeatable − Whatever process is used the primary information required to estimate is: • Scope of what is to be delivered • Delivery capability • Contingency must be included in any estimate in order for it to be realistic − estimates are conditional forecasts that will be affected by future events both internal and external to the project − Events cannot be known with certainty and the estimate must make reasonable allowance for them − Solution development itself is not an exact science − The size of the contingency in an estimate must reflect the degree of uncertainty August 16, 2010 56
  • 57. Estimation Before the project begins properly an estimate must be prepared for the work to be done Pre-project Phase during Feasibility Study phase Estimation Estimate could be a timebox - a fixed team for a fixed period - or could be based on a schedule of workshops and the associated effort to complete the products First estimate for the whole project is prepared towards the end of Feasibility Study Feasibility Study Phase Estimation Rough estimate, based on high level requirements - assist management to assess the value and practicality of continuing with the project Second estimate is produced at the end of the Business Study - scope of the project is decided, the necessary business functionality to be delivered is defined and prioritised, and the system architecture is defined Detailed estimate as it based on the likely major components of the delivered solution Business Study identified from the prioritised requirements Phase Estimation Estimate must reflect a level of risk and confidence that is acceptable to the relevant stakeholders Purpose of this estimate is to plan and schedule the project and used to re-evaluate the August 16, 2010 Business Case to assess whether the project is still viable 57
  • 58. Estimation Detailed estimate from Business Study provides the basis for the whole project, and throughout the remainder of the project this estimate is frequently monitored and revised Functional Model Estimation is performed for each timebox to assess whether the timebox plan is achievable, Iteration Phase and to evaluate the impact on the project if any revisions to the estimate are required and Design and Build Iteration Before the start of each timebox an estimate for the expected work is carried out to ensure Phase Estimation that it remains achievable in light of project experience to date If there is significant deviation from the estimates, the original estimates should be carefully reviewed Until the Implementation Plan is prepared during Functional Model Iteration, there are only Implementation very high level estimates available for this phase Phase Estimation Before the Implementation phase begins, the estimates must be reviewed to ensure they are still reasonable August 16, 2010 58
  • 59. Estimation Techniques • Top Down - estimating by comparison where the proposed project is compared to similar completed projects − Based on the business requirements (rather than system components) − Give a figure for the project as a whole, which may be broken down into phases on a pro rata basis − Fast to prepare − Can be derived from very high level requirements − Give a high level view of the project (its overall cost and timebox) which can be used in evaluating the feasibility of the project • Bottom Up - counting components and other implementation-related information shown in a design and estimating the effort for each of those − Based on tangible system components − Give detailed figures for low level components of the project which can be aggregated to give higher level views − Take time to prepare − Need sufficiently detailed information to allow identification of system components − Provide a good basis for project planning, scheduling and management August 16, 2010 59
  • 60. Collaborative Estimation • Facilitated workshop can be an excellent approach to gaining both sound estimates and buy-in to these estimates from the team and the stakeholders • Participants should, between them, have expertise in all the main technical and business areas covered by the project • Project management and estimation participants • Estimation workshops require considerable preparation in order to achieve their objectives August 16, 2010 60
  • 61. Estimation Guidelines • Use more than one technique to allow cross-checking, e.g. top-down and bottom-up • Produce estimates by workshops involving all stakeholders, rather than by individuals • Ensure the estimate includes sufficient effort for all timebox activities not just those directly resulting in business functionality, including − Project management, team leading, technical co-ordination − User involvement − Non-functional requirements and technical products − Specialist roles, such as business and technical consultants, quality and test managers, security specialists, etc. − Specialist roles, such as business and technical consultants, quality and test managers, security specialists, etc. − Workshop preparation, attendance and follow up, including facilitation and scribing − Completion of project documentation − Quality reviews, inspections, walkthroughs, timebox planning and estimating − Travel and meetings particularly if cross-site − Mentoring if project and/or organisation is new to agile iterative projects − Specialist testing such as stress and performance, or operational acceptance. • Ensure all areas of development are included: avoid focus on pure coding effort • Capture project metrics and feed back actuals vs. estimates into the estimating process • Ensure that anyone who estimates is trained, particularly for specialist techniques such as function point analysis August 16, 2010 61
  • 62. Project Management • Aim of project management is to deliver the right solution on time and on budget using the available resources wisely • Management of traditional projects is about control − Preventing drift from the signed off specification, controlling resources, etc. • Managing an agile project is about enabling constant change while continuously correcting the course of the project in order to maintain its aim at the target - a fixed delivery date for a usable system • To be successful with agile iterative approach, the organisation may have to change organisational, social and technical elements at the same time • All impact on the management of the project August 16, 2010 62
  • 63. Project Management • For tradition projects, the project manager has a detailed plan against which to monitor and control activities • In an agile and iterative project, there are typically more activities going on in parallel − Project Manager has a number of distinctive responsibilities to ensure that the project is under control in each phase • Speed of progress can pose some difficulties for managers from a traditional background in IT project management − If problems arise during a timebox then it is often tempting for the traditional manager to renegotiate the end date as that is what they would normally do − In an agile project, the timebox deadline is fixed usually because it is set by the business need − Consequently, the approved approach is to renegotiate the content of the timebox rather than its duration August 16, 2010 63
  • 64. Project Management • In the agile iterative collaborative approach, there is a great deal of interaction between users and implementers in task completion • Important that communication is clear and concise if rapid development is to be achieved • Agile projects should have an informal but planned communication process • As each timebox is completed, it is the responsibility of the Project Manager to ensure that there is a clear understanding about what is to be delivered in the following timeboxes and to ensure that the relevant requirements are established in detail − Likely that the users will change their minds about priorities and requirements − Project Manger must be open to making such changes whilst ensuring that any consequences are fully understood by the users August 16, 2010 64
  • 65. Project Management • Initial planning • Verify suitability of profile for agile approach • Agree project review and termination evaluation and decision factors Pre-project Phase • Confirm user involvement • Give training in agile approach for all people new to the method • Schedule workshop facilitators • Set up the Feasibility Study team • Attend all workshops • Review/accept and get signoff for the Feasibility Report Feasibility Study • Ensure that all key stakeholders have bought in to the Prioritised Requirements List and Phase the proposed timescales for (incremental) delivery for the project • Create a high-level Business Case for the project • Create the Outline Plan • Schedule Business Study workshop • Manage production of the Business Study products • Attend all workshops • Review and update project risks Business Study • Create the Development Plan jointly with all relevant people • Refine the Business Case and get it agreed by the relevant people Phase • Obtain agreement to proceed into development • Ensure that all project Team Leaders are aware of the contents of the Business Case so that they can use it as the basis for negotiation about what is important within their timeboxes August 16, 2010 65
  • 66. Project Management • Agree individual Timebox Plans with the Team Leaders • Participate in timebox kick-off and closeout meetings Functional Model • Accept all timebox deliverables to the project at each timebox closeout meeting • Monitor the team(s) Iteration Phase • Create the Implementation Plan jointly with all relevant people • Publish the Implementation Plan and get it agreed by the relevant people before the end of the last pass through the Functional Model Iteration • Agree individual Timebox Plans with the relevant Team Leader Design and Build • Participate in Timebox kick-off and closeout meetings Iteration Phase • Accept all timebox deliverables to the project at each timebox closeout meeting • Monitor the team(s) • Manage the migration of the system to the operational environment • Ensure all necessary training takes place in a timely way Implementation • Run the Increment Review workshop and produce the Increment Review Document Phase • Obtain sign-off of the increment from all relevant parties • Plan the next increment if there is one • For the last increment, set the date for the Post-Implementation Review August 16, 2010 66
  • 67. Project Management • Ensure all lessons learnt are made available to other projects Post-project Phase • Participate in the Post-Implementation Review August 16, 2010 67
  • 68. Project Planning • The purpose of project planning is to ensure the success of the project • For agile projects planning is not just an activity that takes place at the beginning of the project - it continues throughout the lifecycle • Planning an agile project can be especially difficult for a project manager used to traditional methods • Agile project plans evolve with more and more detail as the project progresses, as requirements are progressively refined and as lessons are learnt • Plan should address all products generated by, and activities undertaken in, the project − Includes the deliverable products (prototypes, models, documentation, etc.) • Project initiation • Configuration management • Change control • Product breakdown structure • Product descriptions • Risk management • Work instructions August 16, 2010 68
  • 69. Project Planning • Traditional project planning − Focus on agreeing a detailed "contract" with customers about the totality of the system to be delivered along with the costs and timescales − Concerned with understanding the requirements in complete detail so that the right level of resources can be secured and an estimate of the completion time can be made − Plan is created in a great detail and is ideally executed with minimal change • Agile project planning − Focus on setting up a collaborative relationship with the customers, bringing them fully into the make-up of the team − Concerned with agreeing with the users the process by which the business requirements will be met − Initial plans are created in sufficient detail to establish the main parameters of the project and with the firm expectation that the customers will change the plan during the course of the project as they gain a deeper understanding of their needs August 16, 2010 69
  • 70. Pre-project Phase Planning • Objective of pre-project planning is to provide the basis for carrying out the project successfully • Understand the requirements just sufficiently to assess the risks and suitability of the project for an agile approach • Establish the right conditions for the project with the user management • Ensure that the managers from the business have agreed to release their staff into the development team for significant periods of time (including full-time secondment when the project requires it) • Agree a definition of "fitness for business purpose" for the system being developed with the business August 16, 2010 70
  • 71. Agile Project Plans Outline Plan Feasibility Study Phase Means to define and agree the terms and conditions for a successful project and contains as a detailed plan for the Business Study Development Plan Business Study Phase How the project will be carried out and in particular which prototypes will be built and when Functional Model Timebox Plan at the start of each timebox Iteration Phase and Design and Build Refines the Development Plan where each Timebox Plan contains at least one Iteration complete cycle of the Functional Model Iteration or Design and Build Iteration for Phase part of the system Implementation Implementation Plan Phase Defines how the successful implementation of the solution will be achieved August 16, 2010 71
  • 72. Agile Planning Success Factors • The contents of timeboxes are crucial • Plan for deliverables and not activities − Consider the key questions "who, when what, where, how" when planning • Define quality criteria for each deliverable • Plan for frequent delivery of products − Distinguish "delivery to the project" from "delivery to the end user population" • Focus of planning and control in agile projects is on sustaining a high rate of progress, agreeing priorities, keeping relationships healthy, learning as the project progresses, and allowing plans to evolve based on experience gained • Make project planning work by focusing on principles, products, and people rather than methods and techniques • Manage expectations by planning appropriate briefings and training on agile approach, addressing roles and responsibilities, and defining and agreeing products and acceptance criteria • Plan for the use of experienced mentors where there is insufficient experience in the team • Plan to do the work during normal working hours • Plan contingency only for prerequisites (software, hardware, setup, etc.) but not for time or resource on the project itself − Contingency in agile is managed through prioritisation of requirements • Plan for regular daily team meetings • Plan formal reviews at the end of each timebox and establish dates in diaries early • Plan early for testing interfaces, theoretical performance analysis, and performance prototyping August 16, 2010 72
  • 73. Agile Planning Problems • Objectives and requirements that are either too vague or too detailed • Failure to architect the approach • Frequent changes to the schedule for user involvement • Incomplete and conflicting information • Introducing too much change at one time August 16, 2010 73
  • 74. Risk Management • Ongoing process throughout the life of a project • Actively control all the risks facing a project or the implementation of the solution it is delivering − Identification of any and all risks that may threaten the project for business, systems or technical reason − Assessment of the impact of those risks on the success of the project should they arise and deciding on the likelihood of the risk occurring and if it does on the severity of its impact on the project − Management of those risks through defining specific countermeasures that are aimed at either avoiding the identified risks or accepting them and minimising their detrimental effect on the project − Applying the appropriate countermeasures when a risk materialises August 16, 2010 74
  • 75. Risk Management • Risks must be identified and their impact assessed as early as possible • Risks should be continuously reviewed throughout the life of the project, particularly at critical go/no go decision points within the project such as the end of the Business Study and before initiating the development of a new increment • All risks should be assessed in terms of their potential impact • Risks must be actively managed through countermeasures to minimise their possible impact • The emphasis of risk management activities should be on the risks with the highest levels • Projects with risks determined as unacceptable by the Executive Sponsor should not be started • Projects whose risks rise to an unacceptable level should be stopped August 16, 2010 75
  • 76. Risk Log • Opened at the start of the project to assist management in deciding the future of the project − Class of risk (business, systems or technical) − Description of the risk - should be in sufficient detail to be understood by all interested parties but short enough to enable a checklist approach to risk monitoring throughout the project − Likelihood of the risk occurring (high, medium or low) − Severity of impact on the project should the risk occur (high, medium or low) − One or more proposed countermeasures, which will mitigate the risk either by preventing it occurring or by containing when it arises • Countermeasures should include the dates beyond which they are no longer applicable − The status of the risk (open or closed), open risks are still possible, closed risks have either happened and have been dealt with or the time at which they were likely to happen has passed − Owner of the risk (who is responsible for monitoring the risk and/or implementing any countermeasures) • Checklist − Are all the factors potentially affecting the success of the project discussed? − Are risks sufficiently quantified for a decision to be made? − Does each risk have at least one countermeasure identified? August 16, 2010 76
  • 77. Quality Management • Quality of an information technology solution often defined in terms of the way in which that system provides the capability and support required by the user • Agile approach designed to ensure the quality of the project's products − Facilitated workshops ensure that the system's requirements are properly considered at the outset − Continuous and focused user involvement helps to ensure that all parties understand each others - needs and viewpoints − Reviews (whether of prototypes or of supporting documentation) serve to ensure (and record) that the system continues to meet the needs of the business - the quality criteria against which products should be reviewed are identified the Product Descriptions − Thorough testing validates the delivered system against its requirements − Configuration Management and Change Control serve to ensure that quality, once built in to the system, is preserved August 16, 2010 77
  • 78. Quality Planning • Quality planning should be an integral part of the project planning activity − Identification of which products are to be produced and which of those warrant specific quality-related activities − How the quality of each type of product is to be checked - for example by review and/or by testing − When quality checks are to be performed; and whether they are they optional or mandatory, whether or not all examples of a particular type of product must be checked or only a sample, and whether items are checked during development or only on completion − Who is responsible for reviewing and testing each product, who has authority to accept the product and what is to happen if such a review or test is unsuccessful − Which criteria are to be used to assess each product's quality - typically by reference to the quality criteria defined in each of the Product Descriptions − Which procedures are to be used to define quality-related processes − Which records are to be kept to document decisions and actions taken − Which standards are to be applied to products (for example, coding standards and user interface style guides) August 16, 2010 78
  • 79. Quality Audits • Audit projects from time to time in order to determine their compliance with the organisation's procedures, practices and standards • Very important in agile projects that such audits are not allowed to result in unnecessary rework or ineffective effort expenditure • Greatest benefit obtained from audits is frequently in causing corporate procedures, practices and standards to be revised in the light of real experience • Agile-specific audit questions − Is the user involvement there? − Are the users empowered? − Is the life-cycle being followed? − Are comments from prototype reviews being incorporated? − Is backtracking allowed when necessary? − Are priorities being adhered to? − Are timeboxes being respected? August 16, 2010 79
  • 80. Measurement • Measurement is necessary in order to: − Establish a baseline for predicting what will happen in the future − Provide evidence that the process is successful and working − Investigate the process itself in order to highlight and quantify problems • Can provide the information to convince management that the introduction of agile iterative approach can provide tangible benefits to the organisation • Projects should keep careful records of defects classified by severity and type • Success of a project will be whether or not it achieved the stated objectives so these should be described in precise measurable terms − Agile approach is focused on satisfying all of the "must haves" within a fixed elapsed time frame so any measurement of success needs to include all of these August 16, 2010 80
  • 81. Agile Tools and Techniques • Tools and techniques that are applied to agile projects − Workshops − Models and Modelling − Prototypes − Testing − Configuration Management August 16, 2010 81
  • 82. Workshops • Workshop is a structured approach to ensure that a group of people can reach a predetermined objective in a compressed timeframe supported by an impartial facilitator • Benefits − Rapid, quality decision-making • Because all stakeholders are present at the same time, there is great confidence in the result • Group is focused on the objectives to be achieved in the session so that the information gathering and review cycle is performed at a greater speed • Misunderstandings and disagreements can be worked out at the time • Concerns should therefore have been raised and resolved or noted by the end of the workshop − Greater user buy-in • Workshops, run effectively, lead to participants feeling more involved in the project and decisions being made • Build and maintain enthusiasm − Building team spirit • Controlled way of building rapport as well as delivering • Promotes understanding and co-operation between departments - important when a solution involves many groups − Process redesign by the user community • If practices are reviewed as a result of a workshop, participants can gain a greater understanding of the inputs and implications of their work • Leads to improved efficiencies that are led by the participants themselves, giving greater buy-in and commitment • Greater chance of successful implementation − Clarification of requirements when they are unclear • Business users can be led through their objectives and processes to define what they may require • Participants can explore and model ideas • Successful through a combination of structured discussion and the presence of knowledgeable participants August 16, 2010 82
  • 83. Applying Iterative Agile Principles to Workshops • Active user involvement is essential − Workshops provide an ideal format for the business to be directly involved in planning, designing and implementing a solution • A collaborative and co-operative approach between all stakeholders is essential − Create a climate of co-operation within the workshop and enforcing any ground rules for the group to behave effectively − Only possible with the co-operation and commitment of all stakeholders − Effective way of achieving either compromise or consensus • Agile project team must be allowed make decisions − Workshop participants need to be empowered and have the right level of knowledge and authority within the scope of the workshop, so that decisions can be made without delay • Focus is on frequent delivery of products − Structure a workshop so that there are intermediate deliverables − Helps to order participants' thinking as they progress in logical steps − Enables them to work towards an ultimate goal and gives them a growing sense of achievement as the workshop progresses • Fitness for business purpose is the essential measure for acceptance of deliverables − Fitness for purpose is achieved by keeping participants focused on delivery against an agreed set of objectives − Ensure all are involved in decision-making • Iterative and incremental development is necessary to converge on an accurate business solution − Strength of workshops is the synergy achieved by the group − Ideas do not have to be born fully developed but can grow during discussion − Ideal setting to try out ideas with all stakeholders and it is up to the facilitator to provide a safe environment in which this can happen • All changes during solution implementation are reversible − Information and decisions should be recorded as necessary by either one or both of the facilitator and scribe so that ideas can be backtracked where necessary − Often what happens in practice is that an idea or decision is redeveloped • Requirements are baselined at a high level − Objectives must be set during the preparation for a workshop − As the workshop progresses, information is gathered, analysed and interpreted so that discussion can be effective and a decision reached as a result of an increased understanding of the issues involved • Testing is integrated and performed throughout the lifecycle − Because all stakeholders are present, workshop provides the quality control approach of testing ideas and deliverables as they are discussed − Participants can challenge or agree August 16, 2010 83
  • 84. Models and Modelling • Modelling helps the project team gain a good understanding of a business problem, issue or process • Accurate models reflect the realities of the business world • Understanding can be gained by analysing the problem from different viewpoints − Business View - uses a selection of techniques to understand and interpret the business need and to model the business from a future perspective − Processing View - models the system as a set of business processes, or activities, which transform input data items to output data items • Processes can be either combined to form higher level processes, which in turn can be combined again to form yet higher level processes, or decomposed into their constituent sub- processes • Corresponds to the traditional "Why, What and How" type of questioning used during requirements elicitation − Data View - models the business information as a set of objects, or entities, and the relationships that exist between these objects − Behavioural View - models the behavioural characteristics of the system in terms of a set of events and states, where events cause changes in the states of the system. Events may be generated within or external to the system − User Interface View - models the interactions and interfaces between the system user and the system itself August 16, 2010 84
  • 85. Prototypes • Prototypes provide the mechanism through which users can ensure that the detail of the requirements is correct • Demonstration of a prototype broadens the users' awareness of the possibilities for the new system and assists them in giving feedback to the project team • Accelerates the development process and increases confidence that the right system is being built • Types of prototype − Business - demonstrating the business processes being automated − Usability - investigating aspects of the user interface that do not affect functionality − Performance and Capacity - ensuring that the system will be able to handle full workloads successfully − Capability/Technique – testing a particular design approach or proving a concept August 16, 2010 85
  • 86. Testing • In agile projects testing takes place throughout the project lifecycle − Validation - check that a system is fit for business purpose − Benefit-directed testing - testing the parts of the solution that deliver the key business benefits is the highest priority − Error-centric testing - objective of designing and running a test is to find an error − Testing throughout the lifecycle - performed on all products at all stages of the project − Independent testing - a product should be tested by someone other than its creator − Repeatable testing - tests must be repeatable August 16, 2010 86
  • 87. Testing • Testing activities must be prioritised based on the business goals − Overall business process performance (i.e. business processing cycle times) − Large processing volumes (i.e. very frequently occurring events) − Labour-intensive or complex business tasks − Human computer interface, particularly if the computer system will be visible to customers • Efficient use of time available can be made through risk based testing − Identify the risk areas − Assess the impact of errors − Plan for risk based testing − Reduce the risk of errors August 16, 2010 87
  • 88. Configuration Management • Dynamic nature of ale projects means good configuration management is required • Many activities are happening at once and products are being delivered at a very fast rate • Configuration management strategy must be decided and documented in the Development/Implementation Plan before leaving the Business Study phase August 16, 2010 88
  • 89. Iterative Agile Framework • Solution delivery lifecycle is iterative and incremental • Solution is not be delivered in one go, but in a series of increments, which increase what it does each time • Urgent business needs are addressed early while less immediately important functionality is delivered • Users see work under construction, review and comment on it and request changes during the development of an increment • Agile approach provides a generic framework for iterative solution delivery August 16, 2010 89
  • 90. Overall Agile Iterative Process - Phases 1. Pre-Project 2. Feasibility Analysis and Study 3. Business Analysis and Study 4. Functional Model Iteration 5. Design and Build Iteration 6. Implementation 7. Post-Project August 16, 2010 90
  • 91. Overall Agile Iterative Process 6 2 Implementation 4 Feasibility 7 1 Analysis and Study Functional Model Post-Project Pre-Project Iteration Business Analysis and Study Design and Build Iteration 3 5 Sequential Iterated Phases Phases August 16, 2010 91
  • 92. Iterated Phases Agree How Agree How and When To and When To Do It Do It Functional Identify Identify Create Create The Model What Is The Implementation What Is To Be To Be Product Iteration Product Produced Produced Check That It Has Check That It Has Been Produced Agree How Been Produced Correctly and When To Correctly Do It Design and Identify Create What Is The Build Iteration To Be Product Produced Check That It Has Been Produced Correctly August 16, 2010 92
  • 93. Agile Iterative Sequential and Parallel Phases Functional Model Iteration Phase Feasibility Business Pre-Project Post-Project Analysis and Analysis and Design and Build Iteration Phase Phase Phase Study Phase Study Phase Implementation Phase Increment 1 Increment 1 Increment 1 Increment 2 Increment 2 Increment 2 Final Increments Prior Increment P Increment M to Final Implementation Increment N August 16, 2010 93
  • 94. Phase 1 - Pre-Project Phase • Ensures that only the right projects are selected and that they are set up correctly to ensure success • Initial definition of the business problem to be addressed • Decision to proceed with the project • Project manager assigned to the project • Initial project governance in place August 16, 2010 94
  • 95. Phase 2 - Feasibility Analysis and Study Phase • Assessment if iterative agile is the right approach for the project • Feasibility Study should be short and should last no more than a few weeks • Consider using workshop(s) to perform feasibility analysis • Feasibility Study outputs − Feasibility report − Outline plan for implementation − Feasibility prototype − Solution risk log August 16, 2010 95
  • 96. Feasibility Analysis and Study Report • Enables the project steering committee to decide not only which option to choose for the way forward and whether or not the project should proceed beyond the Feasibility Study • Objectives and purposes − Outline the problem to be addressed by the new system − Define the scope of the project or set of projects − Give a preliminary indication of any areas within the scope which may be desirable but not essential − State, at least in outline, the Business Case for the project(s) - including where possible expected costs, benefits, assumptions and risks (whether quantifiable or not) − Indicate what alternative solutions have been or could be considered − Define the major products to be delivered by the project − Report on the suitability of an agile approach for use on the project, which may vary for each solution − Document the objectives of the project including process performance criteria − Document high-level technical and business constraints, e.g. timescale, hardware and software platforms − Identify whether the system may be safety-related or if there may be any product liability issues − Describe at a high level the business processes and data that are expected to be automated − Identify at a high level the interfaces necessary to existing data and applications − Identify which business processes and/or systems (whether automated or not) might be impacted by the new system and which might need to change in order to accommodate it − Define the expected life of the computer system and hence the requirements for maintainability August 16, 2010 96
  • 97. Feasibility Analysis and Study Report Questions and Checklist • Is the problem definition in line with the needs of senior business management? • Is the scope of the project sufficiently clear for it to be refined within the Business Study? • Are the business objectives to be met by the development clearly defined? • Is the solution to the problem, as laid out in the major products to be delivered and in the objectives of the project, feasible in both technical and business terms? • Is the case for the project approach sound and are the risks acceptable? • Does management accept what has been included and excluded from the scope? • Are all associated systems and their interfaces identified? • Is any impact on those systems acceptable? • Is the Business Case for the project to proceed valid? August 16, 2010 97
  • 98. Feasibility Prototype • Feasibility prototype may be produced as a proof of concept for the proposed solution − To prove one or more of the possible technical solutions contained within the Feasibility Report − To demonstrate to the business the possible content of the user interface and the look and feel • Prototype should only be produced if it will really assist the decisions made in the Feasibility Report August 16, 2010 98
  • 99. Outline Plan for Implementation • First planning product within the project • Sets deadlines and milestones for various major phases of work and key deliverables (particularly incremental delivery dates) • Deadlines become the major control points around which the later, lower level plans will be developed • Provides the detailed plan for how the Business Study phase will be run August 16, 2010 99
  • 100. Outline Plan for Implementation • Purpose and objectives − Provide management with ballpark estimates of the financial and resource implications (both project team and user) of the proposed project − Provide a basis for agreement of timescales for the proposed development activities − Define the high-level acceptance criteria for the proposed deliverables such as that the system will conform to all agreed requirements − Define and agree the approach to the Business Study phase − Identify any particular facilities which the project team will require − Define the expected path through the agile framework for the project − Identify any currently known issues surrounding the implementation of the system and in particular aspects such as data take-on and user handover August 16, 2010 100
  • 101. Outline Plan for Implementation Questions and Checklist • Are the estimates for effort realistic in the light of the details within the Feasibility Report? • Are the estimated timescales consistent with the business needs of the project? • have the business needs been addressed in terms of what is delivered and when? • Is business management able to commit to the level of business resources required for the Business Study and to ongoing user involvement for the proposed duration of the project? • Is development management able to commit to the level of development resources required for the Business Study and to ongoing involvement for the proposed duration of the project? • Will all necessary equipment and facilities be available as required? • Is it clear what the criteria for acceptance are and are they rigorous enough to define the quality of deliverables while allowing the requirements to flex during development? • Are all the currently identified standards and guidelines available and for those that are not yet available, are there sufficient resources to enable their development or procurement? August 16, 2010 101
  • 102. Phase 3 - Business Study Phase • Only initiated if Feasibility Study and Report recommends to proceed with solution development • Forms the basis for all subsequent work • Should be kept as short as possible (weeks rather than months) while achieving sufficient understanding of the business requirements and technical constraints to move forward with safety • Focus is on the business processes affected by the solution and their information needs • Phase has to be very strongly collaborative using workshops attended by knowledgeable staff who can quickly pool their knowledge and gain consensus as to the priorities of the development • Key workshop output is the Business Area Definition which identifies the business processes and associated information and the groups/types of users who will be affected in any way by the introduction of the solution • Users who will participate in the solution development will be identified and agreement reached with their management regarding their involvement August 16, 2010 102
  • 103. Business Study Phase Outputs • Business Area Definition • Prioritised Requirements List • Development/Implementation Plan • System Architecture Definition • Updated Solution Risk Log August 16, 2010 103
  • 104. Business Area Definition • Contains a high-level view of the business processes, people and information to be supported by the proposed solution • Evolves into the Functional Model during Functional Model Iteration(s) • Must be in enough detail to enable both the Development Plan and a realistic business case August 16, 2010 104
  • 105. Business Area Definition • Purpose and Objectives − Identify the business needs that should be supported by the proposed solution − Refine the Outline Business Case (documented in the Feasibility Report) to include benefits, risks, costs and impact analyses − Outline the information requirements of the business processes that will be supported − Identify the classes of users impacted by the development and introduction of the proposed system − Identify the business processes and business scenarios that need to change − Clarify all interfaces with other systems (human or automated) − Verify that the proposed solution is still suitable for development using an agile iterative approach August 16, 2010 105
  • 106. Business Area Definition Questions and Checklist • Are the business context, business process and business objectives defined and agreed? • Have all the currently identified requirements been prioritised (including non-functional requirements)? • Have all the priorities been assigned in collaboration with the users? • Have high-level acceptance criteria for the delivered solution been defined? • Are the business areas clearly documented, including high-level information needs that are affected by the system? • Is the envisaged boundary of the proposed new system realistic in the timescales? • Are all classes of users affected by the new system identified? • Are the information and processing requirements of the proposed system defined at least in outline? • Is it still clear that the business needs are being addressed by the proposed new system? • Is the person responsible for each business process identified? Can they commit the necessary resources and time? • Are all major business events (e.g. financial year-end, order received, new supplier taken on) identified? August 16, 2010 106
  • 107. Generating and Managing Requirements • All of the requirements identified during the Feasibility and Business Studies have to be prioritised and recorded so that the most important features will be developed in preference to less essential parts that can be added later if required • Prioritisation will mainly be led by business need but will also need to take into account the technical constraints that may drive some requirement to be satisfied first even though it may be less important in business terms • Some non-functional (operational) requirements, such as security and performance, may also affect the prioritisation • As parts of the solution will begin to be produced in the next phase (the Functional Model Iteration), it is not only important to understand the functionality to be developed but also the system architecture that will be used August 16, 2010 107