1 / 16

Eastern Iowa Agile User Group May 2015

Discover the benefits of implementing a common engineering process in your organization. This article explores key questions and pain points to consider, as well as the basic process definition techniques.

mosesa
Download Presentation

Eastern Iowa Agile User Group May 2015

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Eastern Iowa Agile User Group May 2015 Jeff Dotseth GDIT Director, Software Engineering

  2. Agile Process for your organization . . . Would a common engineering process add value for your organization?

  3. Does your organization need a common process? Questions to ask and pain points to consider: • Do your scrum teams share resources? • Do your scrum teams support multiple Product Owners? • What is the level of Dev or IT staff turnover? • Are there interdependencies across scrum teams? • Do you use the same tools across teams? • How far along is your Continuous Integration and Continuous Deployment implementation? • Is product/service integration an issue? • How much of your process is automated? • How often are your Dev or IT teams working long hours? • Are priorities for Projects, Changes, and unplanned work always clear? • Do your customers have compliance constraints?

  4. Basic Process Definition Techniques • If your organizational analysis shows potential benefits from a standard process • Reduce overhead cost • Reduce individual project risk • Increase repeatability for external customers • Decrease resource team transition effort • Increase team collaboration • Decrease integration efforts and integration risks • . . . then you may consider defining an organizational process • In general as the number of engineering/development teams gets larger and the organization starts to see significant resource growth and/or turnover you will start to see benefits from utilizing common processes. • Take care to recognize the difference between standardization to add business value or to avoid risk/cost vs. standardization to address all the details. • Training vs. required process definition

  5. On the other hand . . . • If your software teams do not have a standard process definition and: • Consistently deliver high quality systems • Respond quickly to change • Are able to scale with business needs • Address and handle project risk in business appropriate ways • Partner with the business to deliver high priority capabilities • Are stable and have low turnover • You don’t need a standard process and others might want to copy what you are doing . . . 

  6. Spotify Engineering Culture - 1

  7. Spotify Engineering Culture - 2

  8. If you aren’t lucky enough to have an organizational culture like Spotify . . . • Some common process definition may be useful and for some organizations it is a requirement for bidding on work. • A recent request from Business Development: In accordance with Attachment 1 . . . describe your company’s software development process and prior experience applying that process. Specifically identify the development methodologies employed, such as agile; configuration management process and tools used, testing methods, test automation software utilized and any other dynamics that fully describe your company's software development process. Describe the tradeoffs, benefits, and risks of your company’s approach.

  9. Collabnet Ideas • Key Elements of Effective Agile Delivery • Guiding principles • Shared responsibility and common goals • Optimizing the entire delivery chain • Extensive and rapid feedback from customers • Embracing change • Essential strategies • Collaboration • Concept of “done” • Continuous improvement • Automation • Continuous delivery • Emerging best practices • Centralize Software IP with governed change management • Build a community architecture with standardizing Agile development processes • Create an Agile Delivery environment for instant elastic provisioning of systems to support continuous delivery to any cloud—private, public, or hybrid clouds Collabnet White Paper: Business Case for DevOps: Continuous Delivery of Value Achieving the Benefits of Agile Delivery & DevOps at Enterprise Scale

  10. How do you start? • How do you think about “a community architecture with standardizing Agile development processes”? • What are the process components?

  11. Standardizing Agile development processes Basic Process Components • Activities contain one or more Tasks • Tasks contain Steps • Steps accomplish Tasks • Roles perform Tasks and are responsible for Work Products • Tasks generate or update Work Products Work Products (Inputs) Tasks and Steps to accomplish Task Roles perform Tasks and are responsible for Work Products Activities Work Products (Outputs) Made available under EPL v1.0

  12. Basic Concepts – Roles – Tasks – Work Products • A Task defines an assignable unit of work (usually a few hours to a few days in length) • Tasks are performed by Roles (one primary, and optionally additional supporting roles) • Tasks have a clear purpose, and provide step-by-step descriptions of the work that needs to be done to achieve the goal • Tasks modify or produce Work Products • Tasks can be performed at any point in the lifecycle • Roles define a set of related skills, competencies and responsibilities • Roles are not individuals or titles • Individuals on the development team may play multiple roles • Roles Perform Tasks • Roles are Responsible for Work Products • Work Products represent the tangible things used, modified or produced by a Task. • Roles use Work Products to perform tasks and produce Work Products in the course of performing tasks. • Work Products are the responsibility of a Role. Made available under EPL v1.0

  13. Additional Concept - Standard • Not required for basic process definition • A standard can be used to tell your teams what information must be included in a work product (but not the format). Valuable when you work with multiple external customers with existing deliverable requirements and/or formats. • Example: The table describes the minimum information that must be captured as part of a Work Item List.

  14. Project Execution Project Management Release Planning, Schedules, Resources, Deliverables, Milestones, Communication, Coordination User Stories to Test Cases Testing Test Plan & Test Cases for the Sprint User Stories User Stories What are we going to build this sprint? Define & Specify Continuous Testing Release Architecture – System Design Development Code, Unit Test, Integration, Version Control, For the sprint requirements (Work Items) User Story Changes Code Changes Defects Configuration & Change Management Platform Version Control, Baselines, CCB Supporting Infrastructure & Tools Dev, Test, Integration & Production Environments, CM Tools, Test Tools, Build Tools, Security

  15. Example Agile Process • GDIT Agile Process Library Open CD folder

  16. GDIT Agile Process Definition • Questions

More Related