WELCOME
In 2016 the Information Systems Group (ISG) approached the programs we supported with a simple question, “How are we doing?” The responses surfaced opportunities for improvement:
- Speed of delivery
- Quality of delivery
- Communications
- Transparency
At that time we made a conscious decision change our delivery model from a phase-gate waterfall approach to a model that was much more agile.. We started changing the culture in ISG and challenging our processes to ensure they provide value and help us deliver for our stakeholders. We also started collaborating with our stakeholders more frequently throughout the development process. We started to require short feedback loops and increased transparency.
This CCSQ Agile Handbook outlines behaviors and practices we expect to take place in our agile way of working. It includes strategic themes that are important to CCSQ. roles and responsibilities in our agile organization, and procedural standards for managing work items to support enterprise metrics, and guidance on meetings & ceremonies.
Lastly, the handbook includes helpful resources for individuals trying to understand how CCSQ is delivering solutions in an agile manner. It talks about how we approach scaling our agile practices for large programs and how we try to reduce overhead on smaller programs.
By no means have we mastered agile, and we are continually striving to get better, but this handbook is a reflection of where CCSQ is on our agile journey. Our hope is that the content hereafter helps individuals understand how CCSQ delivers the solutions for our user community and what our expectations are for CMS employees and contractors alike. As we continue to grow and learn, this handbook will continue to evolve.
SCALED AGILITY
Agility is built upon the Agile Manifesto 1 and Scrum 2 is the preferred framework at CCSQ for practicing Agility. While Scrum provides guidance for a single team, most programs are made up of multiple teams. In this case, the Scrum framework does not explicitly address how to coordinate multiple teams that have dependencies and impediments with other teams. It does not address the overall Vision 9 and alignment of the teams to work on the most valuable items in the backlog. The Scaled Agile Framework 3 takes the principles and practices of Agile and Scrum and applies them to a larger program that is a Team of Teams. This Team of Teams is called an Agile Release Train (ART) 5.
Before a program makes a decision to scale beyond a single team, it must be certain that the scaling is absolutely critical to success. Scaling Agility is based on the Manifesto for Scaling Agility 4. This is an extension of the Agile Manifesto, with a similar structure of values and principles.
If, and when, the Program scales, the Scaled Agile Framework 3 is used as the framework for organizing people and managing the work. Key positions such as the Release Train Engineer (RTE) 6, and an Agile Coach 7 should be filled. The Implementation Roadmap 8 provides a step-by-step guide to transform a Program to Scaled Agility.
AGILE ROLES
Agile Roles clarify responsibilities, expectations, interactions, and outputs from everyone in the organization. Since teams are self-organizing, roles are not about hierarchy and command/control, but about working together to align on value creation and remove impediments.
While there are a wide variety of Agile frameworks used in the industry today, the frameworks deployed at CCSQ are Scrum, Kanban, and SAFe. Scrum 1 and Kanban 3 typically have roles defined at the team level and SAFe 2 has roles defined at the program level.
References
1 - Scrum Guide https://scrumguides.org/scrum-guide.html2 - Scaled Agile Framework (SAFe) https://www.scaledagileframework.com/
3 - Kanban https://www.atlassian.com/agile/kanban
Function | Role | Responsibilities | Ceremonies to Attend | Organization | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Business Owners | Stakeholder Stakeholders provide the business problem to be solved and the value desired. They are the customer, or represent the customer. |
| CMS | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Solution Management TeamSolution Management 1 has content authority for the Solution Backlog. They work with customers to understand their needs, prioritize Epics & Capabilities, create the Solution Vision and Roadmap, define requirements, and guide work through the Solution Kanban.
| Solution Management Team Member The SMT Member plays a similar role to the Product Manager, but at the large solution level and has content authority over Epics & Capabilities, instead of Features. Responsibilities include working with portfolio stakeholders, customers, ARTs and Solution Trains to understand needs and build and prioritize the solution backlog. They coordinate and align with each other to create and maintain the vision, roadmap, solution Kanban, and solution demo activities. They set the priority order of epics and features to align with goals of CCSQ. Because the SMT is made up of several members, it is important that all team members are available for critical meetings and working sessions. SMT usually consists of the ISG Program Manager, Business Owners from other Groups (i.e. SOG, QSOG, iQIIG, QMVIG, etc.), and a Systems Lead/Systems Architect (ISG). It is also common for the SMT to include a Security Officer (SO) or some other Security Lead Role. Both the Systems Lead/Systems Architect and Security Officer members can inform the SMT on non-functional requirements that help determine priorities and scope. |
|
| CMS | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
System Architect The System Architect/Engineering role defines a shared technical and architectural vision for the Solution/Product under development. That includes analyzing technical trade-offs, determining the primary components and subsystems, identifying the interfaces and collaborations between them, defining higher-level functional Nonfunctional Requirements (NFRs), and guiding Enablers through the Solution/Program/Product Kanban. |
| CMS | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Product ManagementProduct Management has content authority for the Program or Product Backlog. They are responsible for identifying Customer needs, developing & prioritizing Features, guiding the work through the Program Kanban and developing the program Vision and Roadmap for their product. | Product Manager Product Managers provide product expertise needed to make strategic product decisions. They analyze user needs and lay out a product vision based on customer demands. They have content authority for defining and prioritizing product features, which are the why, when, and what of the product that the engineering team builds. |
|
| CMS | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Program Support Team |
|
| Non-ADO Support Contractors | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Agile Release TrainThe Agile Release Train (ART) is a long-lived team of Agile teams, which along with other stakeholders, incrementally develops, delivers, and where applicable, operates one or more solutions in a value stream. | Release Train Engineer (RTE) The Release Train Engineer (RTE) is a servant leader and coach for the Agile Release Train (ART). The RTE's major responsibilities are to facilitate the ART events and processes and assist the teams in delivering value. RTEs communicate with program stakeholders, escalate impediments, help manage risk, provide program metrics, and drive relentless improvement. Although ARTs are composed of self-organizing and self-managing teams, trains don't drive or steer themselves on autopilot. That responsibility falls to the RTEs, who operate most effectively as servant leaders. They have a solid grasp of how to scale Lean and Agile practices and understand the unique opportunities and challenges associated with facilitating and continuously aligning a large development program. |
|
| Non-ADO Support Contractors | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Centers of Excellence/Coaching Support At the program level, there may be members of various Centers of Excellence embedded with the ART. These members are experts in various disciplines. They bring knowledge, experience, and an outsider's view to help the ART execute and deliver value. These members will coach on various topics, provide formal and informal training, and help analyze ART performance and value outcomes. To request support for a coach, contact the Lean-Agile Center of Excellence (LACE) | Agile Coach Agile Coaches bring a unique expertise and experience to assist in the transformation and execution of a large program. In SAFe, these are SAFe Program Consultants. Certified SAFe Program Consultants 13 are change agents who combine their technical knowledge of SAFe with an intrinsic motivation to improve the company’s software and systems development processes. They play a critical role in successfully implementing SAFe. SPCs come from numerous internal or external roles, including business and technology leaders, portfolio/program/project managers, process leads, architects, analysts, and consultants. |
|
| Non-ADO Support Contractors | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
TeamsAgile Teams are cross-functional groups of 5 to 11 people who have the responsibility to define, build, test, and where applicable deploy some element of Solution value - all in a short iteration timebox. In a SAFe context, agile teams also include some specialized teams such as Systems Teams for DevOps & Integration, as well as HCD teams and Shared Services teams to support specific overarching functions or skill sets needed for program success. These teams are aligned within the ART to support the delivery of solution value. | Product Owner The Product Owner (PO) is a member of the Agile Team responsible for defining Stories and prioritizing the Team Backlog to streamline the execution of program priorities. The PO has a significant role in quality control and is the only team member empowered to accept stories as done. The PO has ownership over their team's backlog. |
|
| Application | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Scrum Master Scrum Masters are servant leaders and coaches for an Agile Team. They help educate the team on Agile practices, ensuring that the agreed Agile process is being followed. They also help remove impediments and foster an environment for high-performing team dynamics, continuous flow, and relentless improvement.
Upcoming EventsThe LACE offers all of these courses as either public or private. Public means that anyone, CMS and ADOs in CCSQ, can attend on a scheduled date. Private is an offering for members of your program on a date that is negotiated. Public courses are listed in the LACE Upcoming Events. If you don't see a course on the LACE Upcoming Events, you can contact the LACE to schedule a private course, or to request that a public course be scheduled.
Scrum Master TrainingThere are three courses that specifically give you the skills for being a Scrum Master. The LACE offers all of these courses as either public or private. Public means that anyone, CMS and ADOs in CCSQ, can attend on a scheduled date. Private is an offering for members of your program on a date that is negotiated. Public courses are listed in the LACE Upcoming Events. If you don't see a course on the LACE Upcoming Events, you can contact the LACE to schedule a private course, or to request that a public course be scheduled.
Product Owner TrainingThere are four courses that give you the skills needed for Product Owner. The LACE offers all of these courses as either public or private. Public means that anyone, CMS and ADOs in CCSQ, can attend on a scheduled date. Private is an offering for members of your program on a date that is negotiated. Public courses are listed in the LACE Upcoming Events. If you don't see a course on the LACE Upcoming Events, you can contact the LACE to schedule a private course, or to request that a public course be scheduled.
Systems Architect TrainingThere are four courses that specifically give you the skills for being a Systems Architect. The LACE offers all of these courses as either public or private. Public means that anyone, CMS and ADOs in CCSQ, can attend on a scheduled date. Private is an offering for members of your program on a date that is negotiated. Public courses are listed in the LACE Upcoming Events. If you don't see a course on the LACE Upcoming Events, you can contact the LACE to schedule a private course, or to request that a public course be scheduled.
Product Manager TrainingThere are two courses that give you the skills to be a Product Manager. The LACE offers all of these courses as either public or private. Public means that anyone, CMS and ADOs in CCSQ, can attend on a scheduled date. Private is an offering for members of your program on a date that is negotiated. Public courses are listed in the LACE Upcoming Events. If you don't see a course on the LACE Upcoming Events, you can contact the LACE to schedule a private course, or to request that a public course be scheduled.
Product Manager TrainingThere are three courses that specifically give you the skills for being a Solutions Management Team Member. The LACE offers all of these courses as either public or private. Public means that anyone, CMS and ADOs in CCSQ, can attend on a scheduled date. Private is an offering for members of your program on a date that is negotiated. Public courses are listed in the LACE Upcoming Events. If you don't see a course on the LACE Upcoming Events, you can contact the LACE to schedule a private course, or to request that a public course be scheduled.
Team Member TrainingThere are four courses that give you the skills needed for being a Team Member. The LACE offers all of these courses as either public or private. Public means that anyone, CMS and ADOs in CCSQ, can attend on a scheduled date. Private is an offering for members of your program on a date that is negotiated. Public courses are listed in the LACE Upcoming Events. If you don't see a course on the LACE Upcoming Events, you can contact the LACE to schedule a private course, or to request that a public course be scheduled.
OKRs TrainingThere is one course that gives you the skills for OKRs. The LACE offers all of these courses as either public or private. Public means that anyone, CMS and ADOs in CCSQ, can attend on a scheduled date. Private is an offering for members of your program on a date that is negotiated. Public courses are listed in the LACE Upcoming Events. If you don't see a course on the LACE Upcoming Events, you can contact the LACE to schedule a private course, or to request that a public course be scheduled.
DevOps TrainingThere are two courses that give you the skills for DevOps. The LACE offers all of these courses as either public or private. Public means that anyone, CMS and ADOs in CCSQ, can attend on a scheduled date. Private is an offering for members of your program on a date that is negotiated. Public courses are listed in the LACE Upcoming Events. If you don't see a course on the LACE Upcoming Events, you can contact the LACE to schedule a private course, or to request that a public course be scheduled.
SAFe Basics TrainingThere is one course that gives you the skills for SAFe Basics. The LACE offers all of these courses as either public or private. Public means that anyone, CMS and ADOs in CCSQ, can attend on a scheduled date. Private is an offering for members of your program on a date that is negotiated. Public courses are listed in the LACE Upcoming Events. If you don't see a course on the LACE Upcoming Events, you can contact the LACE to schedule a private course, or to request that a public course be scheduled.
Scrum Basics TrainingThere are three courses that specifically give you the skills for being a Scrum Master. The LACE offers all of these courses as either public or private. Public means that anyone, CMS and ADOs in CCSQ, can attend on a scheduled date. Private is an offering for members of your program on a date that is negotiated. Public courses are listed in the LACE Upcoming Events. If you don't see a course on the LACE Upcoming Events, you can contact the LACE to schedule a private course, or to request that a public course be scheduled.
Coaching Corner
LACE Coaches are available for various topics to deep dive into your specific needs.
The LACE offers all of these courses as either public or private. Public means that anyone, CMS and ADOs in CCSQ, can attend on a scheduled date. Private is an offering for members of your program on a date that is negotiated. Public courses are listed in the LACE Upcoming Events. If you don't see a course on the LACE Upcoming Events, you can contact the LACE to schedule a private course, or to request that a public course be scheduled.
User Story ClinicJoin LACE coaches and your peers at CCSQ to work on real world user stories from your backlog. The LACE offers all of these courses as either public or private. Public means that anyone, CMS and ADOs in CCSQ, can attend on a scheduled date. Private is an offering for members of your program on a date that is negotiated. Public courses are listed in the LACE Upcoming Events. If you don't see a course on the LACE Upcoming Events, you can contact the LACE to schedule a private course, or to request that a public course be scheduled.
|
|
| Application Development Organization (ADO) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Team Member (Developer, QA Tester, UX Researcher/Designer, DevOps Engineer, etc.) Agile Teams are cross-functional groups of 5 to 11 people who have the responsibility to define, build, test, and deploy, some element of Solution value—all in a short Iteration timebox. Some teams are skillset focused, such as DevOps and UX. These are also Agile Teams that have a Scrum Master, Product Owner, and backlog. They follow the Scrum and SAFe frameworks for ceremonies and artifacts. |
|
| Application Development Organization (ADO) |
References
2 - Scaled Agile Framework - Enablers https://www.scaledagileframework.com/enablers/
3 - Scaled Agile Framework - PI Planning https://www.scaledagileframework.com/pi-planning/
4 - Scaled Agile Framework - System Demo https://www.scaledagileframework.com/system-demo/
5 - Scaled Agile Framework - Inspect and Adapt https://www.scaledagileframework.com/inspect-and-adapt/
6 - Scaled Agile Framework - Architectural Runway https://www.scaledagileframework.com/architectural-runway/
7 - Scaled Agile Framework - Program Increment https://www.scaledagileframework.com/program-increment/
8 - Scaled Agile Framework - Iteration Review https://www.scaledagileframework.com/iteration-review/
9 - Scaled Agile Framework - Iteration Planning https://www.scaledagileframework.com/iteration-planning/
10 - Scrum Guide - Daily Scrum https://scrumguides.org/scrum-guide.html#daily-scrum
11 - Scaled Agile Framework - Iteration Retrospective https://www.scaledagileframework.com/iteration-retrospective/
12 - Scaled Agile Framework - Business Owners https://www.scaledagileframework.com/business-owners/
13 - Scaled Agile Framework - SAFe Program Consultant https://www.scaledagileframework.com/safe-program-consultant/
14 - Scrum Inc. - Self organizing teams https://www.scrum.org/resources/blog/about-self-organizing-teams
MEETINGS
Program Level/ART Ceremonies
Name | Outcomes | Frequency | Timebox | Attendees |
---|---|---|---|---|
PI Planning |
| Before the start of each Program Increment (every 10-12 weeks) Planned during I&P Iteration | 2 Days | Facilitator: Release Train Engineer (RTE) |
Required: ADO Teams, Scrum Masters, Product Owners, Product Manager(s), System Architect, System Team, Business Owners, Solution Management and Architect (if applicable), COR, Security & Compliance | ||||
Recommended: CCSQ Leadership | ||||
System Demo |
| Once at the end of every Iteration (every 2 weeks) Final integrated PI System Demo would occur during I&A Workshop | 1 Hour | Facilitator: Release Train Engineer (RTE) |
Required: Product Owners, Product Manager(s), System Architect, System Team, Business Owners, Relevant Team Members | ||||
Recommended: Scrum Masters, Solution Management and Architect (if applicable), COR, Security & Compliance | ||||
Inspect & Adapt (I&A) Workshop |
| Before the start of each Program Increment (every 10-12 weeks) Planned during I&P Iteration Occurs before the PI Planning | 6 Hours | Facilitator: Release Train Engineer (RTE) |
Required: ADO Teams, Scrum Masters, Product owners, Product Manager(s), System Architect, System Team, Business Owners | ||||
Recommended: Solution Management and Architect (if applicable), COR, Security & Compliance | ||||
Agile Release Train (ART) Sync |
| Once or twice a week | 30-60 Minutes | Facilitator: Release Train Engineer (RTE) |
Required: Product Owners, Scrum Masters, Product Manager(s) | ||||
Recommended: Relevant Team Members, Solution Management and Architect (if applicable) | ||||
Program Kanban Refinement |
| Continuous (meeting as necessary) | As needed | Facilitator: Product Manager(s) (Feature author/owner) |
Required: Product Owners, Solution Management & Architect (if applicable) | ||||
Recommended: Release Train Engineer (RTE), Scrum Masters |
Team Level Ceremonies
Name | Outcomes | Frequency | Timebox | Required Attendees |
---|---|---|---|---|
Daily Stand Up |
| Daily | 15 Minutes | Facilitator: Scrum Master |
Required: Team Members, Product Owner | ||||
Recommended: Business Owners as needed | ||||
Iteration Planning |
| Once at the start of every iteration (2 weeks) | 4 Hours | Facilitator: Scrum Master |
Required: Team Members, Product Owner | ||||
Recommended: Business Owners as needed | ||||
Iteration Review |
| Once every end of the Sprint (2 weeks) | 1 Hour | Facilitator: Product Owner |
Required: Team Members, Product Owner, Product Manager(s) (Feature author/owner) | ||||
Recommended: Business Owners as needed | ||||
Iteration Retrospective |
| Once every end of the Sprint (2 weeks) Occurs after the Iteration Review and before the Iteration Planning | 1 Hour | Facilitator: Scrum Master |
Required: Team Members, Product Owner | ||||
Recommended: N/A (Agile Team members only) | ||||
Backlog Refinement |
| Continuous (at least 1 or 2 touch-points per Iteration) | As needed | Facilitator: Product Owner |
Required: Team Members, Product Owner | ||||
Recommended: Business Owners as needed |
ARTIFACTS
Expected of CMS
The following artifacts should be created and maintained by CMS (Business Owners, Solution Management, Product Management) and should be provided to ADOs and other Stakeholders.
Vision
The Vision 1 is a description of the future state of the Solution under development. It reflects customer and stakeholder needs, as well as the Feature and Capabilities proposed to meet those needs.
Operational Value Stream Map
Operational Value Streams 1 (OVS) are the sequence of activities needed to deliver a product or service to a customer.
Objectives and Key Results (OKRs)
Objectives and Key Results, or OKRs, for short, are plain language goals and the measures of success for those goals. How do we know what the goal is? How do we know if reached the goal? Does everyone agree on what success is?
The goal of using OKRs for strategic themes 1 is to define and track their progress through concrete, specific, and measurable actions. “OKRs are frequently set, tracked, and re-evaluated – usually quarterly. OKRs exists to create alignment and to set the cadence for the organization. The goal is to ensure everyone is going in the same direction, with clear priorities, in a constant rhythm.”
Program Backlog
The Program Backlog 1 is the holding area for upcoming Features, which are intended to address user needs and deliver business benefits for a single Agile Release Train 3 (ART). It also contains the enabler features necessary to build the Architectural Runway 2.
The Program Backlog is created, refined, and prioritized by Product Management 4.
Expected of Software Development Partners
Team Backlog
Organizing your work into a digestible, transparent artifact is not difficult. The Team Backlog 1 is the primary repository for managing work items. Specifically, User Stories 2. User Stories are discreet value propositions of a larger Feature or Enabler 4 from the Program Backlog 3.
All User Stories will be tracked in Jira. This is because the CMS Jira implementation is able to read Jira projects and collect and collate pertinent metrics associated with team effectiveness.
Value Artifacts
All of the source code, infrastructure as code, documentation, dependencies, and everything else used to create the Value belong to CMS. As such, all repositories, Confluence spaces, etc. are to be provided to CMS.
Required Artifacts:
Personas
"A Persona is a fictitious character embodying a segment of real-world users of your product, website or service. It is based on information gathered via research, both qualitative and quantitative."
HCD Research Methods
HCD practices include many research and testing methods. All artifacts from these methods need to be stored, preferably in Confluence, and available for interested parties and stakeholders.
A comprehensive list of these practices can be found in the HCD Space.
DevOps Metrics
While Team effectiveness metrics are gleaned from Jira projects, DevOps metrics must be provided.
- Deployment Frequency
- Deployment Lead Time
- Mean Time To Restore
- Deployment Failure Rate
Development Value Stream Map
Getting the software value into production is just as important as the software value, itself. Automation, quality gates, package bundling and installation, and software scanning help increase quality and speed of delivery.
Mapping out the Development Value Stream 1 is critical to understand the system and where to focus on improvement opportunities.
All ADOs are required to create and maintain a Development Value Stream Map. This should be available in Confluence.
Getting the software value into production is just as important as the software value, itself. Automation, quality gates, package bundling and installation, and software scanning help increase quality and speed of delivery.
Mapping out the Development Value Stream 1 is critical to understand the system and where to focus on improvement opportunities.
All ADOs are required to create and maintain a Development Value Stream Map. This should be available in Confluence. Learn more about Value Stream Mapping to request the LACE Value Stream Mapping Workshop
REFERENCE
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
Eliminate Waste: Eliminate features, requirements and processes that do not bring value to an end-user
Create Knowledge: Show organizational commitment to knowledge sharing through training, code reviews, pair programming, project documentation, sharing sessions and more.
Build Quality In: Create focus on developing quality in the product and keep on enhancing the development process to reduce defects.
Deliver Rapidly: Focus on delivering software as fast as possible at the highest possible quality. Create stable workflows based on shared understanding of the process.
Empower Teams: Examine failures by checking for gaps in the process rather than looking at individuals as the problem. Allow innovative freedom for teams to identify the best processes and tools.
Delay in Making Decisions: Make decisions at the "Last Responsible Moment" by keeping options open and to learn and gain more knowledge
Optimize the Whole: Focus on the entire value stream from start to finish to eliminate waste and enable faster delivery of value. Sub-optimization of parts of the system may be necessary to optimize the system as as a whole.
If you can achieve your goals with a single team, do not scale. Employ the minimum number of people required to meet your strategic outcomes.
If you have a single team and it cannot deliver effectively using Agile principles and practices, do not scale. Succeed with a single team first.
Respect, trust, and be kind to your people; foster a climate of open, honest, rapid, and empathetic communication.
Continuously reflect and improve across all levels and maintain focus on the whole; prioritize collective high performance over the performance of any individual team.
Keep teams and their work loosely coupled to preserve flexibility; minimize handoffs and dependencies with cross-functional teams and clearly decomposed work.
Radiate information between and among teams to develop shared understanding and promote asynchronous communication; create visibility across the entire work system.
Aim for a minimally viable bureaucracy and nothing more; effective and repeatable practices, policies, and procedures will emerge as you scale.
Decentralize decision-making; push authority to teams so that they can quickly take advantage of emerging opportunities.
Prioritize experimentation for each individual team over conformity across the organization. Celebrate the learning that comes from experimentation—successes and failures—across all teams.
Ensure each team is working towards the shared vision and delivering real value regularly and consistently. Demonstrate progress with frequent validations by stakeholders.
The Testing Manifesto
We value:
- Testing throughout OVER testing at the end.
- Preventing bugs OVER finding bugs.
- Testing understanding OVER testing functionality.
- Building the best system OVER breaking the system.
- Team responsibility for quality OVER tester responsibility.
Human-centered design (HCD) is an intentional process in which the needs, motivations, and limitations of the people using a product or service are considered. The HCD process focuses on user needs and characteristics, usability goals, environment, tasks, and workflow in the research and design of a product and the services that enable it.
As a public organization that promotes civic engagement and seeks to fulfill the charge of OMB Circular A-11 Section 280 (i.e., “Managing Customer Experience and Service Delivery”), CCSQ ISG expects product teams to share this responsibility and find ways to regularly engage with and solicit end user feedback throughout the entire product development lifecycle. ISG recognizes that success is defined, not only by achieving business value through met business requirements, but by delivering high value (i.e., usable and desirable) solutions that meet or exceed the needs and goals of their end users.
TOOLKIT
AGILE EDUCATION