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.
High Quality Software Development with Agile and Scrum
A Practical Agile Approach For A Non Agile Environment
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.
3.
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.
6.
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.
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.
13.
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
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
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
![Agile Project Requirements ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson Copyright 2009-2010, Murray J Robinson www.linkedin.com/in/murrayrobinson](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)