BA Team: Product Ownership, Analysis, and Solution Design BA Bi-Weekly Mini-meeting July 14, 2011 08-2011 Interactive Solutions Delivery Methodology What.

Slides:



Advertisements
Similar presentations
Delivering Enterprise Projects Using Agile Methods Brent Barton May 23, 2006.
Advertisements

Agile Development Primer – Using Roundtable TSMS in an Agile Shop Michael G. Solomon Solomon Consulting Inc.
COPYRIGHT © 2012 ALCATEL-LUCENT. ALL RIGHTS RESERVED. 1 Agile documentation development methodology Giby Panicker and Judith Benjamin 1-Dec-2012.
What is Agile? Agile is a software methodology based on iterative and incremental development, where requirements and solutions evolve through collaboration.
<<replace with Customer Logo>>
Agile 101.
Agile Project Management with Scrum
SCRUM John Drew. SCRUM - overview Scrum is a project management discipline that has evolved since the early 1990s to deliver software that meets business.
The Business Analyst Role in Agile Projects
Agile development By Sam Chamberlain. First a bit of history..
GAI Proprietary Information
Agile Approach: Case Study
COMP 350: Object Oriented Analysis and Design Lecture 2
Managing a Project Using an Agile Approach and the PMBOK® Guide
An Agile View of Process
Introduction to Agile.
> Blueprint Kickoff >. Introductions Customer Vision & Success Criteria Apigee Accelerator Overview Blueprint Schedule Roles & Responsibilities Communications.
Release & Deployment ITIL Version 3
Trusted IT Group. The challenge: 40 active, concurrent IT projects  Unsatisfactory Project Delivery.
What is Business Analysis Planning & Monitoring?
BA Team: Product Ownership, Analysis, and Solution Design BA Bi-Weekly Mini-meeting July 14, Using UI Designer Resources How to make the most.
S/W Project Management
1 Agile Methodology & Programming Ric Holt July 2009.
Tuesday, June 8 th, Agile Development-Successful Delivery & Implementing Across the Enterprise.
Software Engineering- Scrum 徐 瑋 Alen 林芳瑜 Flora 1.
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
Current Trends in Systems Develpment
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
Software Life Cycle Models. Waterfall Model  The Waterfall Model is the earliest method of structured system development.  The original waterfall model.
Interaction Design CMU. Today’s objectives Continue Design approaches (UCD, ACD)  User-Centered Design  Activity-Centered Design.
Chapter 2 Iterative, Evolutionary, and Agile You should use iterative development only on projects that you want to succeed. - Martin Fowler 1CS
SCRUMBAN?!?! What is it and how can it help your team?
THE AGILE MENTALITY CHAPTER Topics  Why Use Agile and Scrum?  Agile Development –Manifesto for Agile Software Development  Scrum Methodology.
1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2.
Project Initiation at The Regence Group 12/19/2015John Garrigues1.
Agile Metrics It’s Not All That Complicated. © 2011 VersionOne 2 Welcome – About your Trainer, Katia Sullivan VersionOne Product Trainer and Agile Coach.
#AgileEd. Using Agile in the Classroom Cindy Royal, Associate Professor Texas State University slideshare.net/cindyroyal #AgileEd.
CSPC 464 Fall 2014 Son Nguyen. 1. The Process of Software Architecting, Peter Eeles, Peter Cripss 2. Software Architecture for Developers, Simon Brown.
Dr. Rob Hasker. What if every project used Scrum?  Why might Scrum not be perfect for every project? Hard to get the big picture Early choices may have.
PV213 EIS in Practice: 06 – Development process 1 PV213 Enterprise Information Systems in Practice 06 – Development process.
WHEN TITLE IS NOT A QUESTION N O ‘WE CAN’ CA Agile Vision Product Manager Michael Lester.
Agile Development Implementation Considerations. Agile software development is a methodology based on iterative and incremental development, where requirements.
Using Scrum to Improve Teamwork, Communication, Quality and Speed
Intelligence and Information Systems 1 3/17/2004 © 2004 Raytheon Company USC/CSE Executive Workshop on Agile Experiences March 17, 2004 A Raytheon Agile.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Agile 101. Feasibility Study SDLC – What is it? Systems Development Life Cycle: The most commonly used, and generally accepted, project management approach..
Agile Development Chapter 10 - part 2. Agile Philosophy  A guiding philosophy and set of guidelines for : developing information systems in an unknown,
Dr. Rob Hasker. Should every project use Scrum?  When might Scrum not be an appropriate model?  What are some of its limitations? Hard to get the big.
Copyright 2015, Robert W. Hasker. Classic Model Gathering Requirements Specification Scenarios Sequences Design Architecture Class, state models Implementation.
Scrum Overview. Agenda What is scrum…and what it isn’t Scrum’s Characteristics The Scrum Process Scrum Phases Measurements Key Practices Backlogs Sprint.
ServiceNow Special Interest Group Phased WorkTemplate Information & Educational Technology 1 DRAFT
Agile Methodology. -Dhanashree Kumkar -Plus91 Technologies.
Informed Traveler Program and Applications Agile / Scrum Overview Jerry Inberg.
Barnes & Noble Alonda Morgan. Agile UX Agile.
Chapter 5 Agile Development Moonzoo Kim KAIST
Approaches to Systems Development
Flight Software Conference 2016
Scrum.
Agile Software Development Brian Moseley.
Chapter 3: The Project Management Process Groups: A Case Study
Approaches to Systems Development
How to Successfully Implement an Agile Project
Summarizing Our Models to Date
Attend|Learn|Grow Taking Your Career to the Next Level
Introduction to Agile Blue Ocean Workshops.
Adjective: Able to move quickly and easily. Principles and Values
Scrum Science NGSS: Engineering, Technology, Applications of Science
Project Lifecycle and IT Product Life Cycle
Scrum in Action.
Presentation transcript:

BA Team: Product Ownership, Analysis, and Solution Design BA Bi-Weekly Mini-meeting July 14, Interactive Solutions Delivery Methodology What it means for Business Consultants

Agile & Scrum: What do the terms really mean? “Agile Software Development is a group of software development methodologies based iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.” We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. “Scrum is an iterative, incremental framework for project management often seen in agile software development, a type of software engineering.” Taken from the sport of Rugby, “Scrum is a maneuver where “the whole process is performed by one cross-functional team across multiple overlapping phases, where the scrum (or whole team) ‘tries to go the distance as a unit, passing the ball back and forth’.” Agile Manifesto

ISDM: Interactive Solutions Delivery Methodology EIM’s Interactive Solutions Delivery Methodology (ISDM) is an end-to-end, project management methodology applicable to the provisioning of customer-driven software & hardware solutions. ISDM uses Agile concepts, and provides guidelines for the initiation and establishment of a project, the initial definition and design of the solution, the iterative build and delivery process that directs value-driven solution implementation, and the ultimate delivery and closure of a project. ISDM requires each project to have a triad of leadership… each area having a representative involved in the project from beginning to end. While the delivery frameworks within ISDM are iterative (Scrums), time itself is linear, and there are linear milestones that need to be met to move a project through from beginning to end.

ISDM High Level Process As part of the Business Consultant group, it is important that we are involved minimally as early as Project Establishment. In each step, different activities are occurring, and specific deliverables will be generated. There may be some variation from project to project, but the goal is to have a high degree of predictability from project to project as to what deliverables are standard. At each gate, deliverables and activities for a step need to be “Done Enough” as determined by the project charter and contract before the project moves into the next step.

Scrum within ISDM Scrum is an iterative framework for executing against a project that defines and requires team members to work together, each performing their role in a synergistic atmosphere. Scrum frameworks are characterized by well defined, team-centric meetings and activities. The frameworks can work with any phase or sprint, not just software development sprints. Sprint Cycles – a series of short phases or releases cycles Daily Scrum Meetings (including customer interaction) Scrum of Scrum Meetings (less frequent) Sprint Planning Meetings (or step planning – prioritizing and committing to work items that need to get done) Tracking of Progress against tasks (burn-down) “End of Sprint Demo” for Build Sprints Retrospective (lessons learned) Frameworks that define how work gets done… Repeat…

ISDM High Level Process In the Establish step, EIM seeks a firm understanding and documentation of the high-level goals and value metrics of the client in order to create a draft project plan, project charter, and all associated artifacts to be delivered to the client. The charter will help determine what “Done Enough” means across the project (agile/waterfall continuum definition and impacts). Establish Contract Initiation Checklist Project Charter Preliminary Schedule Cost Proposal High Level Solution Description Possibly another deliverable, TBD The Business Consultant team will be involved in early discussions with the customer (along with the PM and Tech Lead/Architect), and help minimally define the solution at a very high level (no details). Most likely this is done by a person playing the Product Owner or Solution Architect role. By bringing the BA team in at this level, early estimates will be more accurate. Activities & Deliverables

ISDM High Level Process Define In the Define step, all project requirements, including risks and milestones to be tracked during delivery, are defined. In this step, both the project and the solution are being defined iteratively and collaboratively. Amount of detail defined is determined by the “Done Enough” definition in the project charter (and agreement of all stakeholders). Project Schedule with Deliverables Project Management Plan HW and SW Build Plan QA Approach Training Approach & Transition Approach 2-Layer Solution Description Draft Raw Requirements (Delivery TBD*) The Business Consultant team will be key players in this step, iteratively collecting/reviewing requirements, synthesizing them and working through the UX solution. This may be 1 or more people playing roles of BA, Product Owner, Solution Architect and possibly a UI Designer (although UI Mocks won’t be expected until the Design step). See the Requirements Gathering training module for details of those activities. Activities & Deliverables *We are currently working through guidelines for the raw requirements doc versus a System Requirements Spec, with a goal of pushing a customer commitment to the System Requirements Spec stage. User Login

ISDM High Level Process Design In the Design step, solution features that were identified during the Define step are decomposed into more detailed requirements, then synthesized into a system design at both the User Interaction (UX) level and the underlying technology level. The Design Step produces clarity in what is being built and how it will be built to some degree. Technical Architecture System Management Plan Organizational Communication Plan Prelim Training, Transition & QA Plans Prioritized Feature Backlog (User Stories) Complete SDD UI Mocks System Requirements Specification The Business Consultant team will be key players in this step, iteratively collecting/reviewing requirements, synthesizing them and working through the UX solution. This may be 1 or more people playing roles of BA, Product Owner, Solution Architect and possibly a UI Designer (although UI Mocks won’t be expected until the Design step). See the Requirements Gathering training module for details of those activities. Activities & Deliverables

ISDM High Level Process Build In the Build step, EIM will begin to build the architected solution in an iterative define-design- build-assess-release mini-release cycle. A unique training module will be devoted to the construction of a Build Sprint since the huge majority of time on any project is spent in the Build Step. Detailed Design Specification As Built Documentation if Required QA Plan Release Plan Draft Transition Plan Additional User Stories for Future Backlog Training Templates User Documentation Drafts The BA, Product Owner, Trainer & Writer will be involved during Build sprints. The Product Owner prioritizes both the product and sprint backlogs (working a sprint ahead), and selects the User Stories to be addressed with each Sprint in conjunction with the customer. As the voice of (and liaison to) the customer, the Product Owner holds many clarifying conversations with development and test, and ensures accurate acceptance criteria exists. Other BAs continue to collect and record requirements/User Stories to feed the backlog as necessary. The trainer and Writer begin preparing drafts. Activities & Deliverables

ISDM High Level Process Assess In the Assess step, EIM will execute the final regression testing and User Acceptance testing that must be run against the complete system for customer sign-off. Because there is testing that occurs during each Build Step, the Assess Step in ISDM is much shorter than in more traditional projects. System Acceptance Documentation Defect Tracking Reports Deployment Plans Operational Plans Business Continuity Plans Training Drafts User Documentation Drafts The Business Consultant team will play both a consultative role and active role during Assess, with the BAs and Product Owner clarifying any questions raised by testers re: acceptance criteria and the Writers and Trainers completing their documentation and curriculum. Additionally, UI Designers may need to make last minute updates against any relevant defects or critical usability issues. Activities & Deliverables

ISDM High Level Process Release In the Release step, EIM will move towards the final action of closing out a project. System acceptance documentation, defect tracking reports, deployment and operation plans and a continuity plan will all be turned over to the client prior to Release, as will any user documentation and training materials. Release Notes System Acceptance Operational Impact Assessment Reference Approval and SLA Lessons Learned Final User Documentation Final Training & Documentation Follow-on Backlog (complete) Activities & Deliverables The Business Consultant team will mostly be represented in this step by Training and Documentation, with training likely occurring near the project close date and final documentation deliveries following a similar pattern. Until the project closes, there may be additions to the Follow-on Backlog which need to be managed by the BA and/or Product Owner. If a traceability matrix was required, it likely will also be delivered in this step.

Key points to remember… Summary Our team is involved in every step of a project after it is originated. We get our work done in each step using Scrum frameworks, which are well defined, team-centric iterative guidelines. While ISDM borrows from many Agile principles (including the use of Scrum frameworks), the methodology can accommodate projects with waterfall contractual obligations – the main difference is in the definition of “Done Enough” in the early steps and in the handling of ongoing requirements gathering (change requests) sprint to sprint. ISDM provides frameworks and guidelines that are flexible – allowing the PM to nail down non-negotiables in the Project Charter. ISDM and Business Consultants