Your SlideShare is downloading. ×
A Practical Agile Approach For A Non Agile Environment
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

A Practical Agile Approach For A Non Agile Environment

3,557

Published on

A practical Agile approach for a non agile environment. A real life success story applying Agile methods in a large corporate with high process and software development outsourced, offshore, with no …

A practical Agile approach for a non agile environment. A real life success story applying Agile methods in a large corporate with high process and software development outsourced, offshore, with no automation.

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,557
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
43
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Author Murray Robinson 0411 608 599 murrayr3128@gmail.com http://www.linkedin.com/in/murrayrobinson
  • You can rank the requirements in a software project in order of priority. Often a project does not know all the requirements or their business value at the start of a project If a high value requirement is discovered during a project it can be quite hard to fit in. Sequential projects deliver all the requirements in one big bang iterative feature driven development projects deliver the high value requirements in order of priority each release until the business decides to stop the project or funds run out. Scope is flexible in iterative feature driven development projects.
  • Analysis and design is done one iteration before build and test The design team pulls the top priority unplanned requirements from the requirements back log and designs them in the iteration. The build team pulls the top priority designed requirements from the requirements back log and builds them in the iteration Each team agrees at the start of the iteration what scope they can commit to deliver next iteration with the fixed resource pool available. Management cannot extend the duration or cost of the iteration If towards the end of the iteration the team finds that it cannot deliver all the requirements it committed to then they remove the incomplete requirements from the iteration release and park them for completion in a later iteration. If the team finds that they have completed all the requirements early then they can add the next priority requirements to the iteration. A requirements is only done when it has been accepted by the users and is part of a build packaged for release. requirements that have been built but not passed acceptance testing are not done.
  • Requirements are broken down into things that can be developed and deployed during an iteration. They can include non functional requirements and enabling tasks like set up test environment and deploy build or user guide or operations manual. Each requirements goes through the following statuses: New Analysis Design Build Test Acceptance Deploy Completed
  • Transcript

    • 1. By Murray Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson A practical Agile approach for a non Agile environment
    • 2. Agile Project Requirements
      • Agile implementations focusing on Scrum and Extreme Programming usually require that:
      • You don’t have to follow formal PMBOK or Prince2 processes;
      • You don’t need to produce much formal documentation;
      • Everyone works in one room; including the Business SME’s;
      • All key players including SME’s are full time;
      • The project team is small – 10 to 20 people;
      • The development team is in house or if outsourced can work in house or if external is an experienced Agile team;
      • The development team can automate all tests;
      • The development team can build and integrate continuously;
      • Infrastructure groups and Interfacing systems can deliver supporting changes quickly;
      Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
    • 3. What if your environment is not ideal for Agile?
      • You have to follow formal PMBOK or Prince2 processes;
      • Business and technical team members are in different cities, countries and time zones
      • Business SME’s are only available part time
      • You are required to use an outsourced, offshore software developer with little Agile capability;
      • The team does not have the capability to automate all of their tests or to integrate continuously
      • Infrastructure groups and Interfacing systems have very long lead times;
      • Significant documentation is required for support groups and the next project team;
      Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
    • 4. You can tailor Agile methods to work in a traditional process heavy environment! Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
    • 5. A real life example
      • A large company with a heavy PMBOK waterfall software development process
      • Software development outsourced to a large Indian company with little Agile capability
      • Very complex environment with a large number of interfacing systems
      • IT had just delivered a $30M+ online transformation program that took 18 months and had 200+ people working on it at peak
      • After delivery the Business asked IT to deliver substantial functional and performance enhancements to three projects with remaining budget before the end of the Financial year just 3 months away
      Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
    • 6. Solution
      • Implement an iterative, feature driven, design and development approach within the existing PMBOK process framework
      • Define a small number of general, high level change requests to provide formal process coverage
      • Develop a prioritized feature backlog with business
      • Engage the vendor on a fixed time, capped cost, flexible target scope contract with deliverables defined around features
      • Divide work up into 3 week iterations of analysis, build and test with 3 iterations running at the same time
      • Use HP Quality Centre to manage iterations
      • Use funding left over from the main program
      • Update existing system documents at the end
      Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
    • 7. Results Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Standard project time and cost are based on similar previous projects or based on vendor estimates before Agile applied. Project Time Cost Benefits Delivered Standard Agile Standard Agile Project 1 16 wks 8 wks $500K $450K 16 requirements deployed to production in 8 weeks Project 2 16 wks 14 wks $400K $350K 4 features deployed after 4 weeks, 12 more deployed after 10 weeks and 16 more deployed after 14 weeks Project 3 36 wks 8 wks $1.1M $300K 70%+ performance increase to core purchasing processes deployed to production in 8 weeks
    • 8. Results cont
      • Much lower risk because requirements are delivered every week to UAT instead of in one big bang in the last few days
      • SIT and UAT pass rate increased from 50% to 90% which meant that rework dropped dramatically and the chance of a blowout reduced
      • The business was able to easily introduce and re-prioritise new requirements ahead of lower priority requirements during development.
      • The cost of delivering some (but not all) requirements was lower.
      • Communication with offshore developers was much better and overall the team took more responsibility and was happier.
      • Business, IT and the vendor worked much better together.
      Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
    • 9. How did we do it? Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
    • 10. Aim to deliver high value features rapidly Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson 75% Business Value Release Iteration
    • 11. Iterative Feature Driven Approach Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Deliver small batches of features in short, regular, overlapping iterations - Jeff Sutherland’s Scrum B approach Design, Build & Test Design, Build & Test Design, Build & Test Design, Build & Test Release 1 Release 2 UAT & Deploy UAT & Deploy UAT UAT Iteration 1 Iteration 2 Iteration 3 Iteration 4 Analysis & Design Analysis & Design Analysis & Design Analysis & Design
    • 12. Tailor the standard process Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
      • Use the process tailoring process to tailor out standard deliverables and tailor in agile alternatives
      Other Processes, Deliverables and Reviews Process Phase Tailoring explanation Project Delivery Overview D&B A PowerPoint pack describing an iterative project management and delivery approach to key stakeholders and project team. Replaces the traditional Project Management Plan. Iterative Project Schedule D&B An MS Project Schedule defining the projects iterative plan Requirements captured in Quality Centre D&B Requirements for each feature are defined in QC requirements section. Also known as user stories. Updated Solution Architecture D&B An updated Solution Architecture will be delivered at the end of the release to provide a system description for the next project team. Client Architect to approve. Updated System Requirements D&B An updated set of use cases will be delivered at the end of the release to provide a process description for the next project team. Client Lead analyst to approve. Test Cases for each Requirement D&B Test Cases captured and mapped to Requirements in QC. Approved by Test Manager. Test Summary Report D&B A standard summary of test cases, results and outstanding defects Updated Support Plan D&B An updated support plan will be delivered at the end of the release to provide updated information for the application support team. Approved by Application Manager. Updated Operations Guide D&B An updated operations guide will be delivered at the end of the release to provide updated information for the application support team. Approved by Application Manager. Deployment Run list D&B A spreadsheet defining deployment tasks, assignments, timing and contacts Delivery Retrospective SI Captures lessons learned with input from the team.
    • 13. Use a variable scope contract
      • The scope of this SOW is to improve the functionality and performance of the application in production as much as possible by 30th June 2010.
      • Key Points:
      • Fixed Budget: capped at $XXXK
      • Fixed Time: Start XXXX, End XXXX; In production by 30th June.
      • Fixed Resource Team: the vendor is to provide a named team of people to achieve these objectives.
      • Variable Scope: the target scope is to implement CR’s XX
      • Iterative feature driven design and development approach
        • Scope is broken down into a series of features to be defined in detail.
        • The number, scope, effort and timing for delivery of these features will be agreed jointly between the vendor and the client during the course of the project based on business priorities and remaining time and budget.
        • The scope is capped within the budget and time defined above.
      Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
    • 14. Traditional Team Structure Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Simplified view that does not include Program Managers, GM’s and others Offshore Business Project Manager Business BA IT Project Manager Business SME’s IT Business Analyst Onshore Vendor Project Manager Onshore Vendor Module Lead IT Architect IT Technical SME Offshore Vendor Project Manager Vendor Architect Vendor Module Lead Vendor Module Lead Vendor Functional Test Lead Vendor Performance Test Lead IT Test Manager IT Application Manager Developers Developers Test Analysts Performance Test Analysts
    • 15. Project Plan Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
    • 16. Iteration plan Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
    • 17. The Feature Log Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson A feature is a business requirement or story that can be delivered in one iteration
    • 18. Feature Log in Quality Centre Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
    • 19. A single feature Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
    • 20. Acceptance Test Driven Development
      • Use a manual Acceptance Test Driven Design and Development approach
      • In the Analysis and Design phase the:
        • Test analyst writes acceptance test cases.
        • Business reviews and approves acceptance tests
      • Acceptance Testing
        • One test repeated for system, integration and user acceptance test
        • Developers execute acceptance test cases in integration environment and fix any defects immediately.
        • the vendor Test analyst executes acceptance test cases and developers fix problems immediately.
        • Business SME executes acceptance test cases and developers fix problems immediately.
      • Targeted regression test before deployment
      • SIT and UAT pass rate increased from 50% to 90% which meant that rework dropped dramatically
      Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
    • 21. Project Communications
      • Managing Team Distribution and Time Zones
      • Evenings
        • Offshore Vendor PM meets with their team to discuss what they did that day, what the plan is for the next day and the issues they are having
        • Offshore Vendor PM writes this up and sends to onshore team
      • Mornings
        • PM meets with onshore Vendor PM & Tech SME lead to discuss what the combined team did yesterday, what the plan is for today, the issues and actions to resolve them
      • Afternoons
        • The onshore and offshore business and technical teams meet via Teleconference and Live meeting to discuss progress, requirements, design, testing and issues.
      Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
    • 22. Project Communications cont
      • Managing Interfacing Parties
      • Two to three times a week
        • Managers and module leads meet with each interfacing system manager and vendor
      • Collaboration Tools
        • Quality Centre, Email, LiveMeeting
      • Project Management Tools
        • Quality Centre to track work, document the requirements, solution, test cases and test results
        • PM produces a two page report weekly for management
      Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
    • 23. Challenges
      • Requires Project and Test Managers, Architects and BAs to be :-
        • hands on
        • make fast decisions with less documentation and
        • resolve issues quickly
      • Need to resist requests to extend iterationa to fix extra defects or do more complex changes.
        • move extra work to later iterations
      • Concerns that less formal documentation and review processes will lead to low quality and problems for future projects
        • Overcome by stakeholders seeing features pass in UAT
        • Document requirements and design in QC
        • Update other required documentation at the end
      Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson
    • 24. Challenges cont
      • More code branches and deployments lead to more code merging and management which can cause delays and rework
        • employ better code management software e.g. Harvest or Subversion
      • Distributed team with 70% team offshore and onshore team in different cities and buildings
        • Scrum facilitated through daily team teleconferences
      • Vendor has limited test automation capabilities and facilities
        • Do more manual testing
      • Constraints due to very long delivery times from Infrastructure and Identity Management groups
        • Remove requirements that depend on these groups
      Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson

    ×