Robert R. Betcher.
|
|
- Nathaniel Walsh
- 7 years ago
- Views:
Transcription
1 Simple Enterprise Agile (SeA) (pronounced c for its visibility) for fast, Enterprise to Market Delivery Developed by Robert R. Betcher. Ver. 4.2 (2016) Copyright
2 Table of Contents TIERS 4 PORTFOLIO/PROGRAM 4 TEAM 4 ROLES 5 BUSINESS SPONSOR 5 ERELEASE VICEROY 6 ENTERPRISE ARCHITECT 6 RELEASE VICEROY 7 PRODUCT MANAGER 7 PRODUCT OWNER 8 SCRUM MASTER 8 DEVELOPER OR ENGINEER 8 QA 9 OPS AND DATA-WAREHOUSING 9 MEETINGS 10 AD HOC MEETINGS 10 ROADMAP (RELEASE PLANNING) 10 ERELEASE HUDDLE 10 RELEASE HUDDLE 11 WEEKLY PRODUCT MANAGER MEETING 11 TEAM HUDDLE (STANDUP) 11 TEAM PLANNING (SPRINT PLANNING) 12 TEAM REVIEW/ RETROSPECTIVE 12 ARTIFACTS 13 ROADMAP & RELEASE PLAN 13 WEEKLY PORTFOLIO AND RELEASE HEALTH REPORT 13 BACKLOG 13 TEAM HEALTH REPORT 14 DEFECT BOARD 15 WORK 15 INITIATIVE 15 WORK GROUP 16 PASS 16 WORK PACKAGE (OR STORY) 16 IMPLEMENTATION 16 BUILDING THE SEA IMPLEMENTATION ROADMAP 17 TERMINOLOGY 17 BEST PRACTICES 21 Copyright
3 Introduction Simple Enterprise Agile Faster to Market, Less Documentation, Less Process, Simplistic, and Cheaper to Implement than most Enterprise Agile Frameworks. Simple Enterprise Agile (SeA) is built on a foundation of Keep It Simple (KIS) principles. There are a number of Enterprise Agile Frameworks where there complexity reduces the chances of success. SeA incorporates all the best aspects of Enterprise Agile with fewer Roles, Less Documentation and Fewer Meetings. What does this do for Organizations? It reduces possible points of failure, which ultimately lowers Risk while increasing chances for success. Typical Enterprise Agile implementations have a 1 in 9 chance for success or a less than 12% chance for success. SeA can provide a 78%-91% chance for success by removing/ mitigating the barriers that plague most Enterprise Agile implementations. How does SeA offer such a higher opportunity for success? SeA is far less complex than typical Enterprise Agile Frameworks, which allows the Framework to be implemented expediently with fewer possible points of failure. SeA does not incorporate those Agile ceremonies and processes that are riddled with problems or offer questionable value. SeA, also, has an implementation readiness process to ensure the environment is ready for Enterprise Agile. Included within the framework is a foundation of increased inspection cycles to assist Organizations in making educated decisions for Course Correction. As time to market becomes ever increasingly shorter, Teams and Management often require immediate feedback mechanisms to avoid losing a competitive advantage. Successful projects require an ability to tell whether or not business objectives are being met, and if they aren t meeting business objectives, they need to be able to correct the course quickly to meet ever changing demands. SeA offers crucial feedback to Organizations in real time, rather than after weeks or months have passed. At the end of the day projects have to abide by the Iron Triangle: Budget, Schedule and Quality. It is the equivalent to the law of gravity for project management. With that principle in mind, projects, typically, have a finite amount of time and budget to accomplish a goal. The point of increased inspection cycles offered by SeA is to ensure that the Team can meet the goal within the boundaries of time or money. It is this checks and balances system that offers feedback to management, so they can correct the course and answer some of these questions that always boil to the surface in a project: Copyright
4 Were the goals of the project realistic? Was the budget and timeline realistic? Do we have enough staff to accomplish the goals? Do we have enough time to accomplish the goals? Have our business or technology objectives changed or become out of date? Does the team have too much staff or not enough? Does the team have the tools they need to succeed? Do we have the right team members for this project? Will SeA work in your environment? Sure it will! SeA is built to work in every environment that has staff and tasks. So take the SeA challenge to compare it to your current Framework or Methodology. SeA takes all of the strengths of Agile, while removing areas that are problematic to ensure Enterprises in this new age of business can turn on a dime. Tiers Portfolio/Program Core Business focused. Top Down, business-value-driven approach based on the corner stone questions: Does it make money? Does it save money? Team SeA team tier follows Super SCRUM principles. What is Super SCRUM? Super SCRUM is SeA s variation on tried and true SCRUM Principles. Super SCRUM utilizes 1 Product Owner and 1 SCRUM Master for 3 Teams. Why? SeA embraces Self Organizing and Self Managing Teams to lower Management overhead. SeA s Super SCRUM, has a Standup on M-W-F opposed to everyday where Teams are urged to be collocated to stimulate more osmotic communication. (Note: Teams that are not collocated must have a messenger that allows Video Conferencing and Screen Sharing this must be a stable system that works effectively). Copyright
5 Finally, Super SCRUM does not utilize Test Driven Development or lengthy QA cycles, but Public Defect Boards. Super SCRUM is about building teams around responsible individuals, who are qualified to do the work. It is because of this principle there are only 1-2 testers per 3 teams. (Note: There are instances where Super SCRUM embraces XP programing practices Paired Programming and Refactoring, but never TDD. TDD does not fix the root of programming problems: poor code quality and a lack of code accountability.) Super SCRUM Outline 1) 2 Week Sprints 2) Used for Projects and Ops Teams a. Ops Teams account for Reoccurring Work or Disruptions by using story place holders. 3) All Engineers are Expected to be Proficient 4) 1 PO and 1 SM per 3 Teams 5) Team Size 5-9 6) All Stories Completed in 2 Week Duration No Carry Over 7) All Stories follow standard Description formats and Gherkin Syntax with a fully testable Acceptance Criteria 8) All 3 Teams should never have more than 2 defects per Sprint 9) Standup is M-W-F 10) Team is a mature group that is always working toward continuous improvement 11) All Defects are tracked on the public Defect Board which is submitted to Management each sprint in electronic format 12) Project limited to 6 mos. Roles Business Sponsor This is a key primary role. All work within SeA follows a top down principle where all work should be fully traceable through all tiers. The business sponsor is the voice of the business. They determine the Portfolio/ Program Tier to ensure that it fits into Initiatives and Work Packages answering the two primary questions: Does it make Money?, Does it save money? (Please Note: Is this our core business? should be a qualifying question in the R.O.I. report along with the two primary questions.) All SeA work is based on the cornerstone of delivering Business Value. This ensures that all funds are being spent responsibly without being diverted to Technology Fads that do not offer value. Copyright
6 Responsibilities: Developing Initiatives and Work Groups with Product Managers Deliverables: Initiatives, Work Groups and ROI Report Meetings: Roadmap (Release) Planning, Weekly Product Manager Meeting & Huddles erelease Viceroy The erelease Viceroy is a role within Enterprise environments to coordinate efforts at the Program/ Portfolio tier. The erelease Viceroy can be viewed as an Uber SCRUM Master. They manage the managers to ensure all Teams and Programs are running effectively. The erelease Viceroy, also, coordinates and chairs the erelease Huddle and Roadmap/Release Planning. Included in their duties is the management of Releases. Typically erelease Viceroys manage 3-5 Release Viceroy s at a time. How do they handle this number of releases? It is through organization, meeting management and time management. The erelease Viceroy ensures that the organization stays LEAN. They monitor and review the following regularly: Meetings, Process and Procedures. It is there job to work with the Executives, to review outdated process and procedures. They must also monitor wasteful meetings. Meetings are tremendous productivity killers that can have devastating impacts to the organization. Finally, the erelease Viceroy ensures that all tiers and teams have correctly configured and updated the Application Lifecycle Management(ALM) Tool correctly. Responsibilities: erelease Management, Enterprise Impediment Removal/ Mitigation, LEAN practices and Meeting Audits Deliverables: erelease Report and ekan Ban Board Meetings: Roadmap (Release) Planning (Chair), Weekly Product Manager Meeting & Huddles (Chair) Enterprise Architect The Enterprise Architect is responsible for current and future architecture states within the organization. Mostly, the Enterprise Architect is fully responsible for guiding the organization to solutions that offer value. Furthermore, Enterprise Architects are in place to ensure the Organization avoids Fads or Agendas that deliver little or no value to the environment. Copyright
7 The Enterprise Architect is the Sherpa that guides the business through the murky waters that surround technology and business. These seasoned veterans formulate high level plans (no more than 2 pages) to guide all tiers through a workable plan that meets the business vision. Responsibilities: Enterprise Architecture Deliverables: Architecture Diagrams (Reports in extreme cases) Meetings: Roadmap (Release) Planning & Huddles Release Viceroy The Release Viceroy is exactly how it sounds. This individual s primary focus is ensuring that multiple releases are running effectively. The Release Viceroy coordinates efforts with the Super SCRUM Teams to coordinate the efforts among multiple teams. The Release Viceroy runs the Release Huddle, Mitigates any Impediments and ensures all Teams are running LEAN. The Release Viceroy will manage 3-5 Releases, which should occur no less than every month. The Release Viceroy provides reporting (no more than 1 page) after the completion of each release to the erelease Viceroy. Responsibilities: Release Management and Program Impediment Removal/ Mitigation Deliverables: Release Report Meetings: Roadmap (Release) Planning, Weekly Product Manager Meeting & Huddles (Chair) Product Manager The Product Manager is the A Typical role. They are the voice of the business and ensure all Work Groups meet the businesses vision. They chair the Weekly Product Manager Meeting to coordinate all efforts from the Product Owners. The Product Manager provides a report at the end of the Release to their Business Sponsors (no more than 1 page). This is the culmination of reporting provided by the Product Owners, whereby Product Managers manage 5-10 Product Owners depending on Scope. Responsibilities: Development of Work Groups, User Story Review and Product Owner Management Deliverables: Initiatives and Work Groups Meetings: Roadmap (Release) Planning, Weekly Product Manager Meeting (Chair) & Huddles Copyright
8 Product Owner This is the typical SCRUM Product Owner role, however this individual works with 3 teams opposed to 1. The Product Owner handles the backlog and writes their own User Stories. There are no Product Owner Proxies, Business Analysts or Story Authors in Super SCRUM. All User Stories must be submitted through the Product Owner before being entered into the Backlog. This ensures that the Product Owner is always kept apprised of the content within the Product Backlog. The Product Owner reports to their Business Owners and the Product Manager at the Weekly Product Management meeting. Click Here for more details on the SCRUM Product Owner role. Responsibilities: User Story Development and Backlog Management Deliverables: User Stories and Backlog Maintenance Meetings: Weekly Product Manager Meeting, Sprint Planning, Demo & Huddles SCRUM Master The SCRUM Master is the typical SCRUM Role, except the SCRUM Master works with 3 teams instead of 1. Click Here for more details on the SCRUM Master role. Responsibilities: SCRUM Meeting Reservation & Impediment Removal/ Mitigation Deliverables: End of Sprint Report & Backlog Maintenance Report Meetings: Sprint Planning(Chair), Demo(Chair), Retrospective(Chair) & Huddles Developer or Engineer Super SCRUM is not about managing process, meetings or any other non-value add activity. This is why Super SCRUM focuses on those individuals getting the work done: Developers and Engineers. The Super SCRUM teams are built on a foundation of Self Managing/ Self Organizing teams. Copyright
9 Teams are comprised of mature, responsible individuals, who are experienced in their role. Teams are not comprised of Jr. members or should not have anymore than 1 Jr. Individual per 3 teams to ensure work quality is not impacted. There is a high expectation held for Developers and Engineers within Super SCRUM, where they are expected to be proficient with their responsibilities. This is why there is a high expectation on Code Quality and Engineering practices. Moreover, team members are expected to deliver quality work that delivers value while avoiding Technical Fads. Responsibilities: Development/ Engineering, Testing & Diagraming Deliverables: Engineering/ Development Tasks, Testing and Diagrams Meetings: Sprint Planning, Demo, Retrospective & Huddles QA The QA role is focused on managing business quality opposed to primarily focusing on technical quality. Super SCRUM follows the principles of avoidance and addressing issues at the root, opposed to mitigation. This is why there are public defect boards within Super SCRUM; boards that are about creating code accountability. There are limited Testers per team since all team members are expected to produce quality work (all tasks should be tested at least 3X by individuals completing the work before submitting the work to QA). All Defect boards are maintained by independent QA staff to ensure that there is always truthful reporting. A digital copy of boards are also submitted to Upper Management for review. This is a pivotal step in working toward continuous improvement within Super SCRUM. Responsibilities: General Quality Assurance/ Quality Control Deliverables: Automated Test Scripts and Maintenance of Defect Boards Meetings: Sprint Planning, Demo, Retrospective & Huddles Ops and Data-warehousing The Ops/ Data Warehouse teams still follow Super SCRUM. **They are to account for Operations work and Production Support work. Teams plan for this work by adding story placeholders for these known unknown activities. If these activities do not occur, the team pulls in work to account for the allotted unused story points. Copyright
10 Responsibilities: Project and Operations Work Deliverables: Engineering/ Maintenance/ Development Tasks, Testing and Diagrams Meetings: Sprint Planning, Demo, Retrospective & Huddles Meetings Ad Hoc Meetings Ad Hoc meetings are highly discouraged in SeA. The teams should be in constant collaboration and allowed to conduct small huddles as necessary to avoid productivity impacts or non value add meetings. It is the responsibility of the erelease Viceroy and Release Viceroy to ensure that less than 15% of the staff s time is spent in meetings. Roadmap (Release Planning) The Roadmap/ Release Planning sessions occur monthly for 2 hours. These are not multi day sessions. In all reality, the Roadmap/ Release document is a living document that should be updated regularly in order to avoid lengthy planning sessions. Session Length: Max 2 Hours (or less for Mature Environments) Frequency: Monthly to Bi Monthly Chair: erelease Viceroy (Release Viceroy for Smaller Environments) Participants: erelease Viceroy, Release Viceroys, Enterprise Architect, Product Managers and Business Sponsors Outputs: Roadmap (Release) Plan and Work-package Board erelease Huddle This is the 15 Min. standup every Tuesday and Thursday that follow the basic SCRUM of SCRUMs Principles and 4 questions: 1. What has your team done since we last met? 2. What will your team do before we meet again? 3. Is anything slowing your team down or getting in their way? 4. Are you about to put something in another team s way? Session Length: Max 15 Min. Copyright
11 Frequency: Tuesday and Thursday Chair: erelease Viceroy (Release Viceroy for Smaller Environments) Participants: erelease Viceroy, Release Viceroys, Enterprise Architect, Product Managers and Business Sponsors Outputs: N/A Release Huddle This is the 15 Min. standup every Tuesday and Thursday that follow the basic SCRUM of SCRUMs Principles and 4 questions: 1. What has your team done since we last met? 2. What will your team do before we meet again? 3. Is anything slowing your team down or getting in their way? 4. Are you about to put something in another team s way? Session Length: Max 15 Min. Frequency: Tuesday and Thursday Chair: Release Viceroy Participants: Release Viceroy, Product Managers, SCRUM Masters and Product Owners Outputs: N/A Weekly Product Manager Meeting The Weekly Product Manager Meeting is conducted each week to ensure that teams are aligning with the business vision. This is the time where Business Sponsors, Product Owners and Product Managers meet to discuss items on the Roadmap/ Release Plan and Product Backlogs. Session Length: Max 1 Hour Frequency: Weekly Chair: Product Manager Participants: Release Viceroy (Observer), Business Sponsor (Observer), Product Managers and Product Owners Outputs: Updates to Initiatives, Work Groups and Stories Team Huddle (Standup) This is the typical SCRUM Daily Stand up except it follows Super SCRUM principles of occurring Monday, Wednesday and Friday. The Huddle asks a rendition of the SCRUM Daily Standup 3 Questions: 1. What did you do since the last time we met? Copyright
12 2. What will you complete before we meet again? 3. Are there any impediments blocking your work? Robert R. Betcher Session Length: Max 15 Min. Frequency: Monday, Wednesday and Friday Chair: SCRUM Master Participants: SCRUM Master, Team and Product Owner (Observer) Outputs: N/A Team Planning (Sprint Planning) This meeting is conducted prior to each Sprint. This meeting is 1 to 2 hours long and is about getting a consensus from the team, where Pre-work to prepare for this meeting is encouraged. The group makes sure the points are realistic and that ALL work can be completed during the 2 week Sprint. (Splitting Stories, Carrying Over Stories and Adding Stories would be discouraged and can only be conducted with the use of a Pass). Stories are to be added during this session by the Product Owner and Team Viceroy only. Session Length: 1.5 hrs or less Frequency: 1 Week Prior to Sprint (2 weeks or less) Chair: SCRUM Master Participants: SCRUM Master, Team and Product Owner Outputs: Sprint Backlog Team Review/ Retrospective The last day of the Sprint, the team does a team review. This is where the team gets together for 1 to 2 hours for demos and the team performance review. After the Demos, the SCRUM Master prints out the Sprint Review Report. The team discusses openly what went well in the Iteration and what could be improved upon. In discussing what went well the team should discuss how to duplicate the successes. In discussing what could be improved upon, the team should discuss how to make such improvements. Session Length: 1.5 hrs or less Frequency: After Every 2 Week Sprint (2 weeks or less) Chair: SCRUM Master Participants: SCRUM Master, Team and Product Owner Outputs: Action Items List and Assignments for Improvement Copyright
13 Artifacts Roadmap & Release Plan All work rolls up to the Roadmap/ Release Plan. The Plan is laid out with a list of all Work Groups (or Agile Features). The work is listed in columns that are the Releases (no more than a month). This plan should have all work listed for 3 Releases (6 Releases max to avoid Fortune Telling). Work within the Roadmap is high level and qualified through the R.O.I process within SeA to ensure Business Value is always achieved. SeA always follows a Top Down principle for work. All high level efforts for the Business begins within the Roadmap then funnels down to the next tiers. The Roadmap is a living document where items can be added and removed from future Releases. Carry over work is highly discouraged in SeA; it is better to pull in new work rather than over commit and under deliver on a Release. Weekly Portfolio and Release Health Report Performance Metrics: SeA utilizes a standard Burn-down for the Iteration and Release tiers. It is also the first Agile methodology to track budgets. All metrics are handled by the Viceroys at the Team and Portfolio tiers. Each project tracks the following metrics in the format below: Days Expended Days Points Completed Work Points Budget Expended 2M 3M Dollars Defects Closed Defects Scope Change (pts) Work Points Included in this report is the Impediments Report that is delivered to Upper Management for mitigation (Please Note: The Impediments Report is delivered to Upper Management every Sprint). Backlog All work within SeA is stored in the Product Backlog like most Agile frameworks. The Backlogs are controlled by the Product Management team. Copyright
14 There is an expectation that the Product Backlog is always groomed each week by Product Management. Included in this expectation is that there is always 2 Sprints worth of work groomed for the Teams to ensure Teams do not have to deal with downtime or bottlenecks. While anyone can build Work Groups, Work Packages/ Stories, only the Product Management team can add these to the backlog. This ensures that the Product Management team is fully aware of the work within their backlogs, since backlog maintenance is their responsibility. The Product Backlog is kept in one Application Lifecycle Management tool that offers full traceability. It is discouraged to use any medium for a Product Backlog that lacks traceability (e.g. Spreadsheets, Word Processors, etc ) All Work Groups within the Backlog are formatted with the following fields: 1. Work Group ID 2. Title 3. Release Assignment 4. Description 5. Start Date 6. End Date 7. Cost 8. Owner/ Owners All Work Packages/ Stories within the Backlog are formatted with the following fields: 1. Work Package/ Story ID 2. Title 3. Sprint Assignment 4. Description 5. Acceptance Criteria 6. Owner/ Owners Team Health Report The Team Health Report is a simple report produced from the Application Lifecycle Management tool that has the following components: 1. Burn Down 2. Burn Up 3. Points Committed 4. Points Delivered 5. Defect Count 6. Impediments Copyright
15 Defect Board The Classic Defect Board is the mainstay to Quality Assurance/ Quality Control in SeA. SeA is built upon quality Team Members. Business Leaders, Developers & Engineers are expected to be proficient at their jobs. There is an equal expectation that they test their work thoroughly before deployment. SeA is built on the premise that there is Code/ Engineering accountability to help Teams grow through Continuous Improvement. There is no T.D.D. and lengthy QA cycles at the end of Sprints or Releases. Quality work should always be produced by the Team to limit QA cycles and technical debt. The Defect Board is a public board with those individuals with the most defects listed at the top and those individuals with the least listed at the bottom. There is, also, a copy of the defect board distributed to Upper Management each Sprint and Release. Individuals continuously at the Top of the Board will be placed into the Mentor program within SeA to assist in their development. If mentorship does not work after 2 terms, the individual will need to be reviewed by Upper Management for reassignment to roles more befitting their skillset to ensure they do not impact their teams. Work Initiative All work from the Roadmap or Release Plan ties to an Initiative. An Initiative is a high level breakdown of the work within an Enterprise. An Initiative can be considered a Project but should not span more than 1 year to avoid fortune telling. Long Projects or Initiatives have a very high rate of failure and problems with traceability and accountability. All project work within SeA still adhere to the Iron Triangle: (Budget, Schedule, Quality/Scope) Each Initiative after a year should be evaluated and qualified through the two primary questions: 1. Did the Initiative Make Money? 2. Did the Initiative Save Money? Copyright
16 Initiatives that do not qualify through this process should be considered for sunsetting. Work Group A workgroup is the next tier below an Initiative where a Work Group should not span longer than a Release. A Work Group always connects to an Initiative within SeA and is always assigned to a Release. Work Package (or Story) A Work Package or User Story is the next tier below a Work Group. The Work Package/ Story should always be completed within the Sprint where carry over or splitting stories is highly discouraged. A Work Package or Story always connects to a Work Package and is always assigned to a Sprint. A Work Package or Story uses the A typical Fibonacci sequence for points but has a maximum of 13 points within Super SCRUM guidelines. User Story Points in Super SCRUM do have a relation to effort whether it is Team Days or Developer/ Engineer days to deter Points Padding or Points Inflating by teams. Please note: There are no tasks within Super SCRUM to help teams stay focused on getting the work done, rather than focusing on task maintenance. Pass A Pass is just as it sounds. A Pass allows a team to one time to break the rules of the framework for extreme circumstances. While using Passes are discouraged, there are instances where they are necessary during a Release. Implementation SeA solely works on a Top-Down principle even in its implementation. This begins with training at the Executive tier who must be fully engaged in the transformation of SeA. These ambassadors are fully responsible for the success of SeA where they not only have to Coach their Teams on SeA, they have to enforce the best practices of SeA. Copyright
17 SeA starts with an environment assessment to ensure the cutover to SeA can be 12 mos. or less. Making the switch to Agile is disruptive, and the only real choice Upper Management has in the matter, is how long to allow this disruption to take place. Unlike other methodologies that profit from a lengthy conversion, SeA implementations are designed to be expedient to limit the disruption to the business. Switching to a methodology is disruptive whether it is eased into by the organization or migrated quickly. We advise SeA sites to make the switch quick. Through experience we have found that the shock to the culture is the same whether the environment is eased into the new methodology or converted quickly. NOTE: Waterfall, SDLC or any other process driven methodologies will NOT work with SeA. Mixing the methodology does not offer the best of both worlds. These methodologies are polar opposites, and mixing the two will double costs and create tremendous bottlenecks effecting delivery deadlines and performance. Building the SeA implementation Roadmap Please Note: A SeA transformation for even the most complex Enterprise environment should be less than 1 year. Step 1: Executive Level Training Step 2: Training the Trainers, Product Managers/ Owners, Release Viceroys & SCRUM masters Step 3: Convert Work Packages/ Stories or Old Requirements Backlog Cleanup and Grooming Step 4: Configure Enterprise Resource Planning Software Step 5: Stand up Product Management Office Step 6: Train Teams and Staff Step 7: Cutover Terminology Portfolio/Program layer: This is the high level tier built for Executives. This is where the Business Sponsor s vision is built into a reality by the erelease Viceroy and Release Viceroys who build Releases and Work Group. Release Viceroy and erelease Viceroy: These are the individuals who take all the pieces of the puzzle and pull it into a big picture. In no uncertain terms, they Copyright
18 are Program Managers assisting in coordinating all of the (2-4 Viceroys for each Release Viceroy) Teams efforts for delivery, integration, defect resolution (Work Group level) and impediment removal (Work Group level). The Release Viceroy is also a coach to the Team Viceroys when necessary. The Release Viceroy Lead handles those Large Scale Enterprise environments that may have multiple Release Viceroys (4-8 Release Viceroy s per erelease Viceroy). It is their responsibility to produce the Roadmap/Release Plan and chair those planning meetings. Enterprise Architect: The architect is responsible for the entire enterprise. Their job is to create the Enterprise documentation, Coach and Guide the Teams and ensure that the team is completing all supporting documentation for the Work Group and Work Package/ Story. Documentation: SeA uses Visual LEAN documentation and discourages Textual documentation that often results in miscommunications and rework. There are no Business Requirements Documents, User Requirements Documents, Functional Requirements or Use Cases. SeA operates on a back to basics approach where the focus is getting work done, not producing documentation that is often left unread, test cases that are obsolete after every code release or any other artifact that detracts from the end result: building a workable product. The only documentation is the following: System Flow Chart System Diagrams UI Hierarchy (For Web and Client Applications) Database Diagrams Data Mappings Mockups/ Wireframes 1 Paragraph Max Non Functional Descriptions < 200 char (Counts as 1 Pass) Roadmap/Release Planning: This is a 2 hour meeting 1 week before the Release end. The meeting is about collaboration and consensus where it is highly recommended to do as much pre-work in small huddles before this meeting. It is at this point that there is an agreed upon Roadmap/Release Plan. Once this plan is formulated at the end of the session, there is points forecasting(from prior releases) and attainability discussion to ensure the work can be completed in each release as agreed. The team does a review of the Release Burn-down, then closes the meeting. Roadmap/Release Plan: This is a high level document outlining the Work Group to be delivered over the next 4-6 Releases. It is typically in a column format where the columns are the release and the rows are the Work Group. Underneath each Release there are the cumulative points from each Work Group within the Release. Next to the cumulative points there is the number of points completed during the Release. Copyright
19 Huddle: Huddles are brief where 2-4 team members get together for no more than 30 minutes. The point of huddles is to encourage collaboration, but discourage meetings (statistics have proven that meetings can have a less than 4% chance of a productive outcome, and cost a company between $523-$1709 a meeting.) This framework has specific meetings and limited huddles to ensure that teams are efficient and effective. Meetings outside of the framework are highly discouraged due to the negative impacts on teams productivity. Pass: A pass is a Get Out of Jail Free Card. It allows the team to bend the rules for the methodology in extreme cases. It is not meant to be used more than one time for one instance per Release. The reason why there is a pass card is because extenuating circumstances or known unknowns tend to appear; however, like any tool, if the methodology isn t followed properly, it will offer an optimum result. Release: Every release something goes into production or is ready for production (ready for production is 1 pass). There is always a demo approved by the Product Manager/ Owner that can be given during a huddle at anytime. However, there is always a demo, even if there is not a push into production. Releases are only 1 month maximum to ensure the work is being dissected properly and the team is not over committing while under delivering. Most of all this gives Upper Management the proper feedback for COURSE CORRECTION! A release is allotted what is called a pass. There is 1 pass per Release. Length: 1 Month (2 Months with a Pass) Naming Convention: [Year].[End Month].R[Release Number] Work Groups: Are chunks of work that are delivered in no more than a release. They can be more than a release on extreme instances where there is 1 pass used. The Work Group comprises of a Title (must be in business language the Sponsor can understand), a Description (1 or 2 Sentences of business language/ technical language), Acceptance Criteria (Visual depiction or no more than specified character limit outlined below), a Release, and Points 10, 15, 20, 30 (Team Days). While adding up points of stories work packages should equal a Work Group s points, it often is not the case since this is a high level estimate. Work Group Phases: Architecture, Work, Integrate/Test 1,2,1 Work Group Title: Business Terminology not Technical Terminology Naming Convention: [Initiative]-[3 to 4 word description] (e.g. Customer Portal User Registration Page) Description: 200 Char. Max. (As a [role] I would like [deliverable] to offer [business value]) Acceptance Criteria: The Acceptance Criteria is the Acceptance of all Work Packages Stories. Attachments: Supporting documents meeting the SeA Documents Criteria Copyright
20 Size: 10, 15, 20 or 30 Days Release: All Work Group Must be assigned to a Release Owner: Work Group are owned by the Product Manager and should only be entered by the Product Manager or an individual representing the Product Manager. Work Group are never to be entered without the express permission of the Product Manager to ensure all work ties to business initiatives. Team: Typically (5-9) Individuals comprising of Developers/ Engineers (1 Lead for Support and Documentation) and 1 to 2 Testers. The teams are designed for productivity, which is why there currently is no Test Driven Development (too many conflicting reports concerning the validity of TDD for it to be implemented at this time) or lengthy Unit Testing Cycles. There is a very high work quality standard to be upheld by the engineers where defect visibility is posted on very visible defect board. This creates ACCOUNTABILITY, so that teams can grow and become more effective. Detractors: Individuals that impede the cut over to Agile or SeA. Projects constantly have to combat detractors whether they have their own agendas, enjoy turmoil or need to create turmoil to distract attention from their own shortcomings. Detractors can not be in place if SeA is to be successful. Sprint/ Team Plan: This meeting is conducted once a Sprint, the day the Iteration starts. It is when the Product Manager, Team Viceroy and Team gets together to review the Work Packages/ Stories for the upcoming Iteration. This meeting is 1 to 2 hours long and is about getting a consensus from the team, where Pre-work to prepare for this meeting is encouraged. The group makes sure the points are realistic and that ALL work can be completed during the 2 week Iteration. (Splitting Work Packages/ Stories, Carrying Over Work Packages/ Stories and Adding Work Packages/ Stories are discouraged where any of this can only be done with the use of a Pass). Work Packages/ Stories are to be added during this session by the Product Owner and SCRUM Master only. Sprint/ Team Review: The last day of the Iteration, the team does atteam review. This is where the team gets together for 1 to 2 hours for demos and the team performance review. After the Demos, the Team Viceroy prints out the Iteration Review Report. The team discusses openly what went well in the Iteration and what could be improved upon. In discussing what went well the team should discuss how to duplicate the successes. In discussing what could be improved upon, the team should discuss how to make such improvements. Sprint/ Team Review Report: This report contains how many points the team committed to for the Sprint, how many points delivered, a burn-down chart, a burn up chart, defects and impediments. It is produced in a digital or hard copy to be delivered to the Release Viceroy. Copyright
21 Sprint: These are every 2 weeks. The point of this framework is to offer constant feedback to the Team and Management. It is this checks and balances which gives the framework its value. The iterations are short, since much of the Process and Overhead that slow down the other methodologies have been removed, which allows the team to complete more work in a shorter amount of time. During this time Work Packages/ Stories are completed by the team and accepted by the Product Manager. The Product Manager is allowed to accept Work Packages/ Stories throughout the Iteration. However, adding Work Packages/ Stories during the Iteration is highly discouraged due to the negative impacts it has on reporting. The team should only be committing to Work Packages/ Stories that they know they can complete. Note: Work Packages/ Stories are only allowed to be split, added or carried over with the use of a Pass. Length: 2 Business Weeks (10 days) Naming Convention: [Year].Iteration[Iteration Number] (e.g Iteration3) Parent: Release (e.g R6) Points: Unlike other Agile methodologies, points do connect to effort in SeA. There is a common language that everyone understands: Time and Money (projects typically have a finite amount of time and money). Since, many Agile teams have correlated their points to effort, this system utilizes a straight forward method where 1 point = 1 Team day of effort. It is this system that assists teams in synchronizing deliverables, sharing resources and leveling resources effectively. Most of all, this helps deter teams from Points Padding or using Inflated Points Systems, which can misrepresent the Team s true performance. Activity Log: Is attached to every Story Work Packages, where team members can add notes, % complete and any other details related to a story. While we discourage this detail, teams may add this detail where necessary. Defects: Defects are listed by developer/ systems engineer and if the Engineer is a part of the team that caused the defect, the team gets no points for fixing the defect. If the individuals who fixes the defect does not work for the Team that created a defect, that team can take points for the fix. Defects are listed on a visible defect board. Defect Board: The lynch pen to SeA is creating accountability to improve quality. The defect board is in a visible area where the Engineer with the most defects is listed on the top, and the Engineer is listed on the bottom. The defects are listed next to the Engineer s name, where the defect board is recreated each Iteration. Engineers at the top of the board more than 2 times, must be coached by the Architect to improve quality. Best Practices Copyright
22 Splitting Stories Discouraged during Sprint Spanning Stories Discouraged over multiple Sprints Adding Stories Discouraged, unless absolutely necessary or OPS/ Data No Spreadsheets or Independent Management Documents unless supporting a Story or Work Package Version History: 1.4 (2011), 1.8 (2012), 2.0 (2013), ver 2.2 (2014) Copyright
Agile Scrum Workshop
Agile Scrum Workshop What is agile and scrum? Agile meaning: Able to move quickly and easily. Scrum meaning: a Rugby play Agile Scrum: It is an iterative and incremental agile software development framework
More informationLEAN AGILE POCKET GUIDE
SATORI CONSULTING LEAN AGILE POCKET GUIDE Software Product Development Methodology Reference Guide PURPOSE This pocket guide serves as a reference to a family of lean agile software development methodologies
More informationSmartBear Software Pragmatic Agile Development (PAD) Conceptual Framework
Pragmatic Agile Development (PAD) Conceptual Framework This document describes the Pragmatic Agile Development framework, a Scrum based development process. SmartBear Software 3/10/2010 Pragmatic Agile
More informationIntroduction to Agile and Scrum
Introduction to Agile and Scrum Matthew Renze @matthewrenze COMS 309 - Software Development Practices Purpose Intro to Agile and Scrum Prepare you for the industry Questions and answers Overview Intro
More informationAGILE - QUICK GUIDE AGILE - PRIMER
AGILE - QUICK GUIDE http://www.tutorialspoint.com/agile/agile_quick_guide.htm Copyright tutorialspoint.com AGILE - PRIMER Agile is a software development methodology to build a software incrementally using
More informationWater-Scrum-Fall Agile Reality for Large Organisations. By Manav Mehan Principal Agile consultant Manav.Mehan@tcs.com
Water-Scrum-Fall Agile Reality for Large Organisations By Manav Mehan Principal Agile consultant Manav.Mehan@tcs.com Interests and Experience Leading Change and Transformation in Large, Complex organisations
More informationMeasuring ROI of Agile Transformation
Measuring ROI of Agile Transformation Title of the Paper: Measuring Return on Investment (ROI) of Agile Transformation Theme: Strategic & Innovative Practices Portfolio, Programs & Project (PPP) Management
More informationThe Basics of Scrum An introduction to the framework
The Basics of Scrum An introduction to the framework Introduction Scrum, the most widely practiced Agile process, has been successfully used in software development for the last 20 years. While Scrum has
More informationCertified ScrumMaster (CSM) Content Outline and Learning Objectives January 2012
Certified ScrumMaster (CSM) Content Outline and Learning Objectives January 2012 The following pages present the CSM taxonomy as validated through the 2011 Scrum Alliance Validation Study. Each percentage
More informationCertified ScrumMaster (CSM) Content Outline and Learning Objectives January 2012
Certified ScrumMaster (CSM) Content Outline and Learning Objectives January 2012 The following pages present the CSM taxonomy as validated through the 2011 Scrum Alliance Validation Study. Total questions
More informationAgile Scrum and PMBOK Compatible or Contrary?
Agile Scrum and PMBOK Compatible or Contrary? Paul Despres PMI Emerald Coast Panama City Branch June 26, 2014 Meeting Overview Agenda Topics: Review Agile/Scrum Methods Review PMBOK Structure Demonstrate
More informationDevelopment phase 1.3. isupport. Project Name: isupport Date: 24-6-2015 Release: 1.3. Document Name: HCCH isupport Development phase project team 1
cross-border recovery of maintenance obligations pour le recouvrement transfrontière des obligations alimentaires Development phase Project Name: Date: 24-6-2015 Release: 1.3 Authors: Brigitte Voerman
More informationD25-2. Agile and Scrum Introduction
D25-2 Agile and Scrum Introduction How to Use this Download This download is an overview of a discussion Intertech has with clients on Agile/Scrum This download has an overview of Agile, an overview of
More informationThe Agile Manifesto is based on 12 principles:
The Agile Manifesto is based on 12 principles: Customer satisfaction by rapid delivery of a useful product solution Welcome changing requirements, even late in development Working products are delivered
More informationScrum. SE Presentation. Anurag Dodeja Spring 2010
Scrum SE Presentation by Anurag Dodeja Spring 2010 What is Scrum? Scrum is an agile software development framework. Work is structured in cycles of work called sprints, iterations of work that are typically
More information1. Sprint Planning. Agile Ceremonies Demystified. A four part series written by Angela Boardman, CSM, CSP. www.atginfo.com 1-866-805-4ATG (4284)
www.atginfo.com 1-866-805-4ATG (4284) Agile Ceremonies Demystified A four part series written by Angela Boardman, CSM, CSP 1. Sprint Planning Agile.maybe you have heard of it. Does your company want to
More informationAgile Notetaker & Scrum Reference. Designed by Axosoft, the creators of OnTime the #1 selling scrum software.
Agile Notetaker & Scrum Reference Designed by Axosoft, the creators of OnTime the #1 selling scrum software. Scrum Diagram: Team Roles: roduct Owner: Is responsible for what goes into the product backlog
More informationIMQS TECHNOLOGY AGILE METHODOLOGY
IMQS TECHNOLOGY AGILE METHODOLOGY OVERVIEW Agile software development refers to a group of software development methodologies that promotes development iterations, open collaboration, and process adaptability
More informationAgile Information Management Development
Agile Information Management Development Agile Project Management Characteristics Acceptance and even welcome of changing requirements Incremental product delivery Define, develop and deliver early and
More informationRoles: Scrum Master & Project Manager
Roles: Scrum Master & Project Manager Scrum Master: Facilitate collaborative meetings Track team performance Remove impediments (Risk, Issue) Validate team alignment to Agile framework and scope Drive
More informationManaging Agile Projects in TestTrack GUIDE
Managing Agile Projects in TestTrack GUIDE Table of Contents Introduction...1 Automatic Traceability...2 Setting Up TestTrack for Agile...6 Plan Your Folder Structure... 10 Building Your Product Backlog...
More informationWhat is Scrum? Scrum Roles. A lean approach to software development. A simple framework. A time-tested process
What is Scrum? From http://www.scrumalliance.org/pages/what_is_scrum A lean approach to software development Scrum is an agile software development framework. Work is structured in cycles of work called
More informationScenarios for Pair Coaching Exercises
Scenarios for Pair Coaching Exercises by Brett Palmer and Victor Bonacci presented at Agile2016 Atlanta (July 28, 2016) Downloads available at AgileCoffee.com/paircoaching Scenario 1 User story mapping
More informationTransitioning Your Software Process To Agile Jeffery Payne Chief Executive Officer Coveros, Inc. jeff.payne@coveros.com www.coveros.
Transitioning Your Software Process To Agile Jeffery Payne Chief Executive Officer Coveros, Inc. jeff.payne@coveros.com www.coveros.com 1 About Coveros Coveros helps organizations accelerate the delivery
More informationIntroduction to Agile Scrum
Introduction to Agile Scrum by Julia M. Lobur Penn State Harrisburg CMPSC 487W Fall 2015 Introduction to Scrum Learning Goals Relationship of Scrum to other Agile methods Scrum Framework Scrum Roles Scrum
More informationA Glossary of Scrum / Agile Terms
A Glossary of Scrum / Agile Terms Acceptance Criteria: Details that indicate the scope of a user story and help the team and product owner determine done-ness. Agile: the name coined for the wider set
More informationWho Doesn t Want to be Agile? By: Steve Dine President, Datasource Consulting, LLC 7/10/2008
Who Doesn t Want to be Agile? By: Steve Dine President, Datasource Consulting, LLC 7/10/2008 Who wants to be involved in a BI project or program that is labeled slow or inflexible? While I don t believe
More informationIssues in Internet Design and Development
Issues in Internet Design and Development Course of Instructions on Issues in Internet Design and Development Week-2 Agile Methods Saad Bin Saleem PhD Candidate (Software Engineering) Users.mct.open.ac.uk/sbs85
More informationOptimizing Your Software Process
Optimizing Your Software Process Top 5 Software Development Process Challenges Executive Summar ry A process framework is a combination of project management, technical practices, and supporting tools.
More informationWould you like to have a process that unlocks ability to learn and produce faster?
Would you like to have a process that unlocks ability to learn and produce faster? Agile - your unfair advantage in the competition. BUILD LEARN MEASURE DEFINED MEASURABLE REPEATABLE COLLABORATIVE IMPROVABLE
More informationIntroduction to Agile Practices
Introduction to Agile Practices Phyllis Marbach, INCOSE Agile Systems & Systems Engineering Working Group February 2, 2016 INCOSE INSIGHT July 2014 1 Current State of Intelligent Transportation Systems
More informationScrum in a Large Project Theory and Practice
Scrum in a Large Project Theory and Practice Agile World 2012 Munich, July 12, 2012 Dr. Sebastian Stamminger Scrum in Large Projects Agenda Theory Case Study Teams Our Process Challenges Lessons Learned
More informationEXIN Agile Scrum Foundation. Sample Exam
EXIN Agile Scrum Foundation Sample Exam Edition June 2016 Copyright 2016 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system
More informationQuality Assurance in an Agile Environment
Quality Assurance in an Agile Environment 1 Discussion Topic The Agile Movement Transition of QA practice and methods to Agile from Traditional Scrum and QA Recap Open Discussion www.emids.com 2 What is
More informationAdopting Agile Testing
Adopting Agile Testing A Borland Agile Testing White Paper August 2012 Executive Summary More and more companies are adopting Agile methods as a flexible way to introduce new software products. An important
More informationExecutive Guide to SAFe 24 July 2014. An Executive s Guide to the Scaled Agile Framework. alshall@netobjectives.com @AlShalloway
An Executive s Guide to the Scaled Agile Framework Al Shalloway CEO, Net Objectives Al Shalloway CEO, Founder alshall@netobjectives.com @AlShalloway co-founder of Lean-Systems Society co-founder Lean-Kanban
More informationIteration Planning. also called Iteration Kickoff
Agile Practices also called Iteration Kickoff Iteration Planning Purpose: Discuss detailed requirements of the stories to be built in the iteration. Review and refine the acceptance criteria for each story
More informationVision created by the team. Initial Business Case created. Cross functional resource meeting held. Agile alignment meeting
Help Tips Agile SDLC Product Backlog Daily Standup Sprint 1 Show and Tell 2 Week Sprint Sprint 2 Release1 (must haves) Retrospective Sprint 1 DONE! Sprint 3 Sprint 2 DONE! Sprint Backlog Sprint 3 DONE!
More informationWaterfall to Agile. DFI Case Study By Nick Van, PMP
Waterfall to Agile DFI Case Study By Nick Van, PMP DFI Case Study Waterfall Agile DFI and Waterfall Choosing Agile Managing Change Lessons Learned, Sprints Summary Q and A Waterfall Waterfall Waterfall
More informationRAPID ENGINEERING WITH AGILE RIGHTSHORE DELIVERY (REWARD)
RAPID ENGINEERING WITH AGILE RIGHTSHORE DELIVERY (REWARD) A cost-effective, out of the box approach that combines agile development with an optimised Rightshore team REWARD Flexible, manageable and cost-effective
More informationEvaluation of agility in software development company
Evaluation of agility in software development company Gusts Linkevics Riga Technical University, Riga, Latvia, gusts@parks.lv Abstract Organization s and team s experience in agile methodology can be more
More informationLeveraging Agile and CMMI for better Business Benefits Presented at HYDSPIN Mid-year Conference 2014 28-Jun-2014
Leveraging Agile and CMMI for better Business Benefits Presented at HYDSPIN Mid-year Conference 2014 28-Jun-2014 Outline 2 Context Key Business Imperatives Agile Adoption and CMMI Roadmap CMMI+Agile Best
More informationChapter 6. Iteration 0: Preparing for the First Iteration
Chapter 6. Iteration 0: Preparing for the First Iteration People only see what they are prepared to see. Ralph Waldo Emerson There are no secrets to success. It is the result of preparation, hard work,
More informationSometimes: 16 % Often: 13 % Always: 7 %
SCRUM AT RIIS A Standish study found that only 20% of features in a typical system were used often or always and 45% of features were never used at all. The ability to embrace change is critical to reducing
More informationAgile Processes and Distributed Projects: Dream or Nightmare?
Agile Processes and Distributed Projects: Dream or Nightmare? Instructor: Kevin Thompson, Ph.D., PMP, ACP, CSP 4100 E. Third Ave, Suite 205, Foster City, CA 94404 650-931-1651 www.cprime.com The leader
More informationAgile and lean methods for managing application development process
Agile and lean methods for managing application development process Hannu Markkanen 24.01.2013 1 Application development lifecycle model To support the planning and management of activities required in
More informationAgile with XP and Scrum
Agile with XP and Scrum Amit Goel National Agile Software Workshop @ Indore Agile India Conference Agile Software Community of India Disclaimer and Credits Most of material in this presentation has been
More informationScrum vs. Kanban vs. Scrumban
Scrum vs. Kanban vs. Scrumban Prelude As Agile methodologies are becoming more popular, more companies try to adapt them. The most popular of them are Scrum and Kanban while Scrumban is mixed guideline
More informationAgile project portfolio manageme nt
Agile project portfolio manageme nt Agile project & portfolio summit at Harrisburg University May 9, 2016 Agile project portfolio management Agenda Portfolio management challenges Traditional portfolio
More informationThe Team... 1 The Backlog... 2 The Release... 4 The Sprint... 5 Quick Summary... 6. Stakeholders. Business Owner. Product Owner.
Scrum In A Nutshell Scrum is about Teams producing Results in an agile way. Scrum Teams achieve results anyway they can by using a simple set of rules to guide effort. We will describe scrum as a simple
More informationAn Introduction to Agile Performance Management
! 1 An Introduction to Agile Performance Management by Jeffrey B. Rothman, Ph.D. An Introduction to Agile This is a high level introduction to Agile -- a well known productivity framework for software
More informationAGILE & SCRUM. Revised 9/29/2015
AGILE & SCRUM Revised 9/29/2015 This Page Intentionally Left Blank Table of Contents Scrum Fundamentals Certified Course... 1 Scrum Developer Certified (SDC)... 2 Scrum Master Certified (SMC)... 3 Scrum
More informationAgile Planning & Metrics That Matter
Agile Planning & Metrics That Matter www.agileforgovernment.com Transformation Strategy & Roadmap Agile & Cultural Training AgilityHealth Assessments Coaching AgileVideos.com About Me Sally Elatta Sally@AgileTransformation.com
More informationOverview of Scrum. Scrum Flow for one Sprint. 2015 SCRUMstudy.com. All Rights Reserved. Daily Standup. Release Planning Schedule. Create.
Overview of Scrum Scrum is the most popular Agile framework. It is an adaptive, iterative, fast, flexible, and effective method designed to deliver significant value quickly and throughout a project. Scrum
More informationGovernments information technology
So l u t i o n s Blending Agile and Lean Thinking for More Efficient IT Development By Harry Kenworthy Agile development and Lean management can lead to more cost-effective, timely production of information
More informationIntroduction to Agile Software Development Process. Software Development Life Cycles
Introduction to Agile Software Development Process Presenter: Soontarin W. (Senior Software Process Specialist) Date: 24 November 2010 AGENDA Software Development Life Cycles Waterfall Model Iterative
More informationUsing the Agile Methodology to Mitigate the Risks of Highly Adaptive Projects
Transdyne Corporation CMMI Implementations in Small & Medium Organizations Using the Agile Methodology to Mitigate the Risks of Highly Adaptive Projects Dana Roberson Quality Software Engineer NNSA Service
More informationAgile Based Software Development Model : Benefits & Challenges
Agile Based Software Development Model : Benefits & Challenges Tajinder Kumar Assistant Professor, IT Department JMIT Radaur, Haryana Vipul Gupta Assistant Professor, IT Department JMIT Radaur, Haryana
More informationThe Agile Project Manager
The Agile Project Manager PMI Madrid, 29/1/2014 1 Jose Barato Consulting, Training and Tools in Project Management PMPeople (Managing Director) PMI Madrid Chapter (Director) PM-IB (founder, Vice-President)
More informationAgile Project Management and the Real World. Emily Lynema DLF Fall 2010 November 1, 2010
Agile Project Management and the Real World Emily Lynema DLF Fall 2010 November 1, 2010 Outline Why care about project management? Traditional vs. Agile What is Agile? What is Scrum? Agile case study:
More informationGetting Started with Agile Project Management Methods for Elearning
Getting Started with Agile Project Management Methods for Elearning Megan Torrance TorranceLearning Training2013 Session 108 February 18, 2013 8am Megan Torrance has 20 years of experience in the learning
More informationT14 "TIMELINES, ARTIFACTS AND OWNERS IN AGILE PROJECTS" Hubert Smits Rally Software Development BIO PRESENTATION 6/21/2007 1:30:00 PM
BIO PRESENTATION T14 6/21/2007 1:30:00 PM "TIMELINES, ARTIFACTS AND OWNERS IN AGILE PROJECTS" Hubert Smits Rally Software Development Better Software Conference & EXPO June 18-21, 2007 Las Vegas, NV USA
More informationScrum. Speaker: Dan Mezick Email: info@newtechusa.com. URL: NewTechUSA.com. http://www.newtechusa.com Copyright 2002: All rights reserved
3 Roles, 3 Ceremonies, 3 Artifacts, 3 Best Practices Scrum Speaker: Dan Mezick Email: info@newtechusa.com Phone: 203-234-1404 URL: NewTechUSA.com Scrum s THREE ROLES The actors in Scrum: Product Owner,
More informationEXIN Agile Scrum Foundation
Sample Questions EXIN Agile Scrum Foundation Edition September 2013 Copyright 2013 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing
More informationAgile extreme Development & Project Management Strategy Mentored/Component-based Workshop Series
Overview This is a 15-day live facilitator-led or virtual workshop is designed to prompt your entire team to work efficiently with Microsoft s Application Lifecycle Management solution based around Visual
More informationGroup Assignment Agile Development Processes 2012
Group Assignment Agile Development Processes 2012 The following assignment is mandatory in the course, EDA397 held at Chalmers University of Technology. The submissions will be in the form of continuous
More informationAgile Metrics. It s Not All That Complicated
Agile Metrics It s Not All That Complicated Welcome About your Trainer, Katia Sullivan VersionOne Product Trainer and Agile Coach Certified Scrum Master Certified Scrum Product Owner Led teams/org s to
More informationDevOps: Development Challenges and New Approaches
DevOps: Development Challenges and New Approaches Chris Sharp STSM, Chief Architect SWG Europe DevOps IBM Master Inventor, Member of IBM Academy of Technology Agenda The Problem and the Need for Change
More informationSmarter Balanced Assessment Consortium. Recommendation
Smarter Balanced Assessment Consortium Recommendation Smarter Balanced Quality Assurance Approach Recommendation for the Smarter Balanced Assessment Consortium 20 July 2012 Summary When this document was
More informationAgile Projects 7. Agile Project Management 21
Contents Contents 1 2 3 Agile Projects 7 Introduction 8 About the Book 9 The Problems 10 The Agile Manifesto 12 Agile Approach 14 The Benefits 16 Project Components 18 Summary 20 Agile Project Management
More informationThere are 3 main activities during each Scrum sprint: A planning meeting where: the Product Owner prioritizes user stories in the product backlog
There are 3 main activities during each Scrum sprint: A planning meeting where: the Product Owner prioritizes user stories in the product backlog that need to be implemented during the sprint the Team
More informationAn Agile Project Management Model
Agile Project Management Jim Highsmith Chapter 5 An Agile Project Management Model We improve effectiveness and reliability through situationally specific strategies, processes, and practices. One of the
More informationIntegrating Scrum with the Process Framework at Yahoo! Europe
Integrating Scrum with the Process Framework at Yahoo! Europe Karl Scotland Yahoo! Europe kjscotland@yahoo.co.uk Alexandre Boutin Yahoo! International alexandre.boutin@yahoo-inc.com Abstract Large enterprise
More information44-76 mix 2. Exam Code:MB5-705. Exam Name: Managing Microsoft Dynamics Implementations Exam
44-76 mix 2 Number: MB5-705 Passing Score: 800 Time Limit: 120 min File Version: 22.5 http://www.gratisexam.com/ Exam Code:MB5-705 Exam Name: Managing Microsoft Dynamics Implementations Exam Exam A QUESTION
More informationCertified Scrum Master Workshop
Learn, understand, and execute on the three overarching principles behind Scrum: iterative development, selfmanagement, and visibility. Even projects that have solid, well-defined project plans encounter
More informationScrum: A disciplined approach to product quality and project success.
Scrum: A disciplined approach to product quality and project success. CQAA February 23, 2011 Patricia Rotman Introductions Copyright 2011-2 Alternate Titles Considered Scrum: Just do it! Scrum: It only
More informationThe style is: a statement or question followed by four options. In each case only one option is correct.
AGILE FOUNDATION CERTIFICATE SAMPLE FOUNDATION QUESTIONS WITH ANSWERS This document is a set of sample questions, in the style of the Agile Foundation Certificate Examination, which is a 60 question, 1
More informationAgile software development
Agile software development Syed Nisar Hussain Bukhari Scientist-B DOEACC centre Srinagar nisar.bukhari@gmail.com Abstract: The field of software development is open and dynamic. New approaches of software
More informationScaling Scrum. Colin Bird & Rachel Davies Scrum Gathering London 2007. conchango 2007 www.conchango.com
Scaling Scrum Colin Bird & Rachel Davies Scrum Gathering London 2007 Scrum on a Slide Does Scrum Scale? Ok, so Scrum is great for a small team but what happens when you have to work on a big project? Large
More informationRational Team Concert. Scrum Project Management Tutorial
Rational Team Concert Scrum Project Management Tutorial 1 Contents Contents... 2 1. Introduction... 3 2. Terminology... 4 3. Project Area Preparation... 4 3.1 Adding Users and specifying Roles... 5 3.2
More informationBridging the Gap Between Acceptance Criteria and Definition of Done
Bridging the Gap Between Acceptance Criteria and Definition of Done Sowmya Purushotham, Amith Pulla sowmya.sudha@gmail.com, amith.pulla@intel.com Abstract With the onset of Scrum and as many organizations
More informationAgile Team Roles Product Owner & ScrumMaster. Brian Adkins Rick Smith
Agile Team Roles Product Owner & ScrumMaster Brian Adkins Rick Smith Agenda Scrum & Team Roles Overview Product Owner ScrumMaster Existing Roles Scrum Teams Optimally about 7 people Sponsor Stakeholders
More informationGlossary SAFe 4.0 for Lean Software and Systems Engineering
Agile Architecture Agile architecture is a set of values and practices that support the active evolution of the design and architecture of a system, concurrent with the implementation of new business functionality.
More informationAn Agile Approach to Metrics :
An Agile Approach to Metrics : Applied Macromeasurements to Ensure On-Time Delivery This article challenges the value of traditional metrics for managing product development schedules and presents a reality-based
More informationAgile Essentials for Project Managers Keys to Using Agile Effectively With Project Teams
Agile Essentials for Project Managers Keys to Using Agile Effectively With Project Teams 1 Greg Smith Agile Coach/Trainer: Certified APM, CSM, PMI-ACP Co-author of Becoming Agile in an Imperfect World
More informationMastering the Iteration: An Agile White Paper
Rally Software Development Corporation Whitepaper Mastering the Iteration: An Agile White Paper Dean Leffingwell Abstract: The heartbeat of Agile development is the iteration the ability of the team to
More informationCapstone Agile Model (CAM)
Capstone Agile Model (CAM) Capstone Agile Model (CAM) Approach Everything we do within the Capstone Agile Model promotes a disciplined project leadership process that encourages frequent inspection and
More informationHow To Be Successful At An Agile Software Engineering
"Agile Software Engineering" Overview for external offering of ASE ABAP Juergen Heymann, CPO Software Engineering There are many ingredients for successful software projects Experienced Developers Domain
More informationAgile Project Management and Agile Practices Training; with a Scrum Project that you will do.
1 PMI Agile Certified Practitioner (PMI-ACP) workshop course details. We are unique and specialists in Agile! Your workshop trainer by passion and is a senior Agile Coach who coached many teams and Kanban
More informationCourse Title: Managing the Agile Product Development Life Cycle
Course Title: Managing the Agile Product Development Life Cycle Course ID: BA25 Credits: 28 PDUs Course Duration: 4 days (with optional Executive session) Course Level: Intermediate/Advanced Course Description:
More informationWE ARE FOCUSED ON HELPING OUR CLIENTS WORK SMARTER AND MORE EFFICIENTLY SO THAT TOGETHER, WE CAN EMPOWER PEOPLE TO DELIVER GREAT RESULTS.
WE ARE FOCUSED ON HELPING OUR CLIENTS WORK SMARTER AND MORE EFFICIENTLY SO THAT TOGETHER, WE CAN EMPOWER PEOPLE TO DELIVER GREAT RESULTS. We believe that people working towards common goals are capable
More informationThe Agile PMO. Contents. Kevin Thompson, Ph.D., PMP, CSP Agile Practice Lead cprime, Inc. 4100 E. Third Avenue, Suite 205 Foster City, CA 94404
The Agile PMO Kevin Thompson, Ph.D., PMP, CSP Agile Practice Lead cprime, Inc. 4100 E. Third Avenue, Suite 205 Foster City, CA 94404 Kevin.thompson@cprime.com Abstract The development of Agile processes
More informationScrum Methodology in Product Testing : A Practical Approach
Scrum Methodology in Product Testing : A Practical Approach Suman Kumar Kanth Sumankumar_kanth@infosys.com Mobile: +91 9937285725 Infosys Technologies Limited Proceedings for the session 1. Challenges
More informationAn Example Checklist for ScrumMasters
An Example Checklist for ScrumMasters Michael James (mj4scrum@gmail.com) 14 September 2007 (Revised 24 July 2012) A Full Time Facilitator? An adequate ScrumMaster can handle two or three teams at a time.
More informationOrthogonal Defect Classification in Agile Development
Orthogonal Defect Classification in Agile Development Monika Jagia, IBM Software Group India, monika.jagia@in.ibm.com Seema Meena, IBM Software Group India, seemeena@in.ibm.com 2008 IBM Corporation Copyright
More informationAgile Project Management in a Regulated Environment
Paper AD06 Agile Project Management in a Regulated Environment Alistair Dootson, d-wise, Manchester, UK ABSTRACT Scrum is an agile approach to project management for software development or implementation,
More informationMariusz Chrapko. Before: Software Quality Engineer/ Agile Coach, Motorola, Poland. My Public Profile: http://www.linkedin.
Gathering Customer Requirements in an Agile Environment Mariusz Chrapko ReConf 2009, Munich Mariusz Chrapko Now: Process Consultant/ Agile Coach@Kugler Maag CIE, Stuttgart Supported Areas: - CMMI - SPICE/
More informationIntegrating gsix Sigma THINKING into Scrum-Based. Darian Rashid Agile Trainer and Coach darian@agileethos.com
Integrating gsix Sigma THINKING into Scrum-Based Development Environments Darian Rashid Agile Trainer and Coach darian@agileethos.com Lean Six Sigma THINKING in Software Development What is Six Sigma Thinking
More informationCrossing the DevOps Chasm
SOLUTION BRIEF Application Delivery Solutions from CA Technologies Crossing the DevOps Chasm Can improved collaboration and automation between Development and IT Operations deliver business value more
More informationAgile Certification: PMI-ACP
Agile Certification: PMI-ACP Agenda What is PMI-ACP? Should I get certified? Contrast ACP to PMP Prerequisites Exam Content What to focus on? How to prepare? Resources Merits or demerits of certifications
More information