WELCOME
In 2017 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
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
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
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
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
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
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
OKRs Training![]() There 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
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
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
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
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
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
|
|
| 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
Title | Description | Version | Audience | Applies to |
---|---|---|---|---|
Team Readiness Checklist when forming agile teams. | 1.0 | RTE, Scrum Master | Team Execution | |
The Capacity Workbook can be used to help team members establish available bandwidth for individual/multiple team members across one or more teams. The workbook should help reduce the time it takes for teams to plan while increasing consistency and accountability among team members. | 1.0 | RTE, Scrum Master | PI Planning, Sprint Planning | |
PI Planning Toolkit | Provided by Scaled Agile, Inc. | 1.0 | RTE | PI Planning |
LucidsPark PI Planning Template | Enhanced PI Planning template to support CCSQ Programs in their distributed planning. | 1.0 | RTE | PI Planning |
Iteration Planning Checklist | Provided by Scaled Agile, Inc. | 1.0 | Scrum Master | Sprint Planning |
Provided by Scaled Agile, Inc. | 1.0 | Scrum Master, Product Owner | Sprint Planning, Sprint Review | |
Use the worksheet to set the business value for PI Objectives | 1.0 | Scrum Master, Product Owner, Development Team | PI Planning | |
WSJF For Features | Use the worksheet to calculate the WSJF for Features | 1.0 | RTE, Product Management, Solution Management Team | Program Backlog Refinement |
Standing Up a New Scrum Team - Checklist | Use this checklist when standing up a new team | 1.0 | Scrum Master, RTE | Team Execution |
Sprint Planning Agenda | Use this agenda during Iteration Planning | 1.0 | Scrum Master, RTE | Iteration Planning, Team Execution |
LACE Guidance on working remotely | 1.0 | Everyone | Program Execution |
AGILE EDUCATION
The LACE has Agile Coaches that are certified to deliver Agile, Scrum, and SAFe training. Below is a calendar of upcoming trainings, and the entire Course Catalog. You can join a public training (all LOBs and Programs can attend), or you can schedule a Program specific training.
Upcoming Trainings
Training/Event | Description | Date(s) | Time | Registration |
---|---|---|---|---|
LACE Community Event: Mission Impact | What is Mission Impact? How can we use it to determine the importance of the work we do? When every requirement is critical, it can be difficult to know what to do first. |
| 1:00 PM - 2:00PM (ET) | |
UX & Agile for Software Development | There is a common misconception that design and development are at odds. One prioritizes understanding and the other prioritizes solutioning. Lean, agile, and human-centered design philosophies are meant to be complementary approaches to getting work done. During this three-hour course, co-facilitated by the CCSQ Lean-Agile Center of Excellence (LACE) and the Human-Centered Design Center of Excellence (HCD CoE), attendees will discuss and explore how teams can thoughtfully integrate design and development needs, share responsibility, and achieve a balanced approach to delivery.
Who is this training for?
Are there any pre-requisites for taking this class?
|
| 1:00 PM - 4:00PM (ET) |
Course Catalog
LACE Foundations Training: LACE Training provides foundational learning in a fun and engaging way, covering Agile and key roles in Scrum: Technical Team, Scrum Master, and Product Owner.
LACE Explained Training: The LACE Explained trainings are short and highly focused training session to provide a deeper look at activities and practices at the team, program and organization level.
LACE Foundations: Agility
What is Agile? What are the foundational principles? Learn about Scrum, Kanban, and SAFe, as well as how the core principles of Agile are applied to digital product development.
In this course, you will gain an understanding of:
- Agile Values and Principles
- Social Contracts – The Glue of Agile
- Key Agile Roles
- Scrum Overview
- Agile Requirements
- Visualizing Work
- Writing User Stories
- Estimation and Planning
Who should attend:
Anyone who is interested in the learning about the history and basics of Agility.
Duration: 2 Days, 10 AM - 4 PM
- Level: Introductory
- Catalog Number: F-100
Learning Path(s): Foundational Learning Path, Agility Generalist
LACE Foundations: Product Ownership
While the role and responsibilities of the Product Owner can be described simply enough, very little is said about the day-to-day practice of those fulfilling the role. If you are a new Product Owner, you may be wrestling with competing demands for time and information from your team and stakeholders. Or perhaps you have been a Product Owner for a while. If so, are you working long hours trying to keep up with the work? Either way, join us to learn the tools to help maximize your potential.
This workshop will teach you how to handle the complex responsibilities of a great Product Owner including: how to manage and prioritize product backlogs utilizing business value and other industry prioritization methods, plan releases, track progress, estimate business value, drive a Sprint Review, effectively prepare and participate in Sprint Planning and learn how to scale Scrum projects. Leave with the skills and renewed excitement to generate business value and fully leverage your Scrum team.
In this course, you will gain an understanding of:
- Why Agile?
- What is Agile?
- Social Contracts – The “Force” of Agile
- Scrum
- Key Agile Roles
- Product Owners and SAFe
- Agile Requirements
- Backlog Management
- Leading the conversation
- Transparency and Reporting
Who should attend:
The Foundations of Product Ownership course is suitable for existing Product Owners, Scrum Masters, Agile Coaches, Team Leaders, Portfolio Managers, Program Managers and those working with Products.
- Duration: 2 Days, 10 AM - 4 PM
- Level: Introductory
- Suggested Prerequisites: Foundations of Agility
- Catalog Number: P-100
Learning Path(s): Product Management
LACE Foundations: Scrum Mastery
No matter how long you have been practicing Scrum, Foundations of Scrum Mastery is the next few pieces of the puzzle. It is a true immersion into the world of a Scrum Master in a SAFe environment. We will explore facilitation, teaching, modeling, and coaching to drive measurable results. We take the time to utilize techniques that help the Delivery Team, Product Owner, and the organization succeed.
The class is full of real-world examples from the participants’ experiences and coaches through practical tools and techniques that can be implemented immediately at your workplace. The course is a deep dive with hands-on activities and exercises to demonstrate key concepts.
In this course, you will gain an understanding of:
- Why we do Agile
- Agile Principles
- Agile Social Contracts
- Key Roles of Scrum
- Scrum Ceremonies
- Agile Estimation
- Key Agile Metrics
Who should attend:
The Foundations of Scrum Mastery course is suitable for existing Scrum Masters, Agile Coaches, Team Leaders, Project Managers, and others assuming the role of an Agile Team facilitator.
- Duration: 2 Days, 10 AM - 4 PM
- Level: Introductory
- Suggested Prerequisites: Foundations of Agility
- Catalog Number: C-100
Learning Path(s): Agile Facilitation and Coaching
LACE Explained: Agile for Non-Technical Teams
What is Business Agility? How can a business be Agile? In this foundational course we will explore concepts from the world of Agile software development and examine how they are being applied to a multitude of disciples, and learners will work together to identify processes issues that Agile methodologies and practices can mitigate.
In this course, you will gain an understanding of:
- Business Agility Best Practices
- The benefits of adopting Business Agility
- Applying Agile Practices for Business Teams
- Business Agility implementation within CMS
Who should attend:
Anyone who is interested in the Business Agility buzzword. Business teams who are interested in the adoption of agility practices.
- Duration: 2 Hours
- Level: Introductory
- Suggested Prerequisites: Foundations of Agility
- Catalog Number: B-102
Learning Path(s): Business/Leadership
LACE Explained: CCSQ LACE Dashboards
Understanding Agility Metrics:
The CCSQ LACE dashboard is available for all Scrum and Kanban teams within CCSQ. For those unfamiliar with Agility Metrics, this short session will include a walkthrough of the team dashboard, an overview of each dashboard element, and how to set up the dashboards.
This session will also help learners interpret and understand the stories the dashboard elements tell, and how to leverage the dashboards to ask the right questions to help accelerate the maturity, health, and speed of delivery of your programs.
Who should attend:
Program Leaders, Product Managers, Scrum Masters, and anyone else with a vested interest in elevating team performance.
- Duration: 1 Hour
- Level: Introductory
- Catalog Number: F-107
Learning Path(s): Agility Generalist
View the Dashboard
Does your program use Jira Portfolio?
View the Portfolio Dashboard
LACE Explained: DevOps
Have you ever wondered what people are talking about when DevOps comes up? You know the buzzwords: Continuous integration, CI/CD pipeline, automated deployments, etc. The DevOps explained session is an overview of attributes, benefits, and practices of the culture of DevOps, and will help you understand participate in conversations with teams and stakeholders about DevOps.
In this course, you will gain an understanding of:
- What is DevOps
- Continuous Integration/Continuous Deployment (CI/CD)
- The DevOps Process
- DevOps Practices and Technologies
- The Evolution of IT Services
- Leveraging DevOps for Organizational Improvement
Who should attend:
The DevOps Explained session is appropriate for anyone who wants to know what DevOps actually is, understand the practices and its impact on software quality, and how it is one of the critical skill sets of software agility.
- Duration: 2 hours
- Level: Introductory
- Catalog Number: C-104
Learning Path(s): Agility Generalist, Technical Agility
LACE Explained: Work Estimation
What is a large? What is a 5?
You may have heard, or experienced, these types of estimates given to backlog items. What do they mean? Who decides what the result is? What does estimating work mean? Who estimates?
All of these questions, and more, will be answered when you attend the LACE Explained: Estimating Work training.
In this course, you will gain an understanding of:
- The science of estimation
- Imprecise estimation
- How estimates drive delivery plans
Who should attend:
Team Members, Product Owners, Scrum Masters, Product Managers, and just about everyone that is involved with creating products and services in CCSQ.
- Duration: 2 hours
- Level: Introductory
- Catalog Number: C-101
Learning Path(s): Agility Generalist, Scrum Master/Coaching, Technical Agility, Business Agility
LACE Explained: Kanban
What is Kanban? What are the rules? Where did it come from? What is the difference between an agile team being a Kanban team and an agile team using a Kanban? Unravel these mysteries and more in the LACE Kanban Explained 2 hour session.
In this course, you will gain an understanding of:
- The Fundamental Rules of the Kanban Board
- How can Kanban identify and reduce waste
- How Kanban teams operate
- Design and Implement a Kanban board
- Kanban Metrics
Who Should Attend:
Scrum Masters, Program Leaders, or anyone using a Kanban for personal or professional use who wants to use a Kanban board to increase throughput and tune their process.
- Duration: 2 hours
- Level: Introductory
- Catalog Number: C-102
Learning Path(s): Agility Generalist, Scrum Master/Coaching, Technical Agility, Business Agility
LACE Explained: Inspect and Adapt
Agile Teams highly regard the scrum Retrospective meeting, understanding it's the key to continuous improvement. How do we realize the Agile Continuous Improvement Principle at the program and organizational level? Attend this class to dive into the details, roles and responsibilities, and activities of the Inspect and Adapt Workshop.
In this course, you will gain an understanding of:
- The value and purpose of the I&A Workshop
- The core modules of the workshop
- Identifying and refining systemic issues that impeding ART performance
- Simulate a problem-solving workshop
Who should attend:
Any member of the ART or that wants to see their program embrace continuous improvement.
- Duration: 2 hours
- Level: Intermediate
- Catalog Number: C-200
Learning Path(s): Agility Generalist, Scrum Master/Coaching
LACE Explained: Objectives and Key Results
What are OKRs?
Writing clear objectives has been a program level challenge since the dawn of SAFe. In SAFe 5.0, Objectives and Key Results have become the preferred way of expressing the business goals at both the program and team levels, and how to measure them. Learn how to write effective OKRs in this short format learning session.
In this course, you will gain an understanding of:
- What OKRs are
- OKR benefits and why companies are using them today
- Best practices for writing OKRs
- Experience writing OKRs through exercises and examples
- Common OKR mistakes to avoid
- How to strengthen the key results
Who should attend:
Program Leaders, Product Managers, Product Owners, and anyone else with a vested interest in empowering teams and programs to support value driven business goals.
- Duration: 2 hours
- Level: Intermediate
- Catalog Number: B-200
Learning Path(s): Business Agility, Product Management, Agile Facilitation/Coaching
LACE Explained: Organizational Quality Practices
Product Quality is an organization effort from the time an idea is formed until we receive feedback from end users. Join us for this session to see the whole picture on quality and how the entire program owns and creates quality.
In this course, you will gain an understanding of:
- The impact and cost of software defects
- What “Built-in Quality” means
- The 5 areas of quality practices in the Software Development Life Cycle
- Ways to measure quality
Who should attend:
Anyone interested in improving product quality.
- Duration: 90 Minutes
- Level: Introductory
- Catalog Number: F-105
Learning Path(s): Agility Generalist, Scrum Master/Coaching, Technical Agility
LACE Explained: PI Planning
In this two hour learning session, we deep dive into the ceremony of PI Planning. We will demystify the agenda, expectations of participants, the intended outcomes, and what to do after it is completed. The value of PI Planning cannot be overstated, and skimping on, or skipping, any part of it is detrimental to the success of the ART.
In this course, you will gain an understanding of:
- Business Value
- PI Objectives
- Committed vs. Uncommitted objectives
Who should attend:
Anyone working with an Agile Release Train (ART)
- Duration: 2 hours
- Level: Introductory
- Catalog Number: F-102
Learning Path(s): Product Management, Agile Facilitation/Coaching Path
LACE Explained: Program Backlog Management
This two hour learning session, the art and technique of managing program backlogs will be demystified. Learners will see how to understand the program backlog in the context of the larger product vision, what preparation is needed for and the mechanics of the program backlog refinement meeting, Feature refinement, the program Kanban, and the PI Roadmap.
In this course, you will gain an understanding of:
- The purpose, procedures and techniques used at the Program Backlog Refinement
- The inputs, outputs, and success measure of Program Backlog Refinement
- What a well-refined feature looks like
- Processes and tools to manage work at the Program Level
Who should attend:
Solutions Management Teams, Product Management, Product Owners, RTE
- Duration: 2 hours
- Level: Introductory
- Catalog Number: P-101
Learning Path(s): Product Management, Agile Facilitation/Coaching Path
LACE Explained: Product Innovation Thinking
How do product managers brainstorm? When in the HCD cycle should we ideate on our user research? This course traces the history of two products that have existed throughout history and gives the participants the opportunity to ideate and find ways to improve the product in the future.
Who Should Attend:
Product Managers, Product Owners, and anyone else with a vested interest in product development.
- Duration: 4 hours
- Level: Intermediate
- Catalog Number: B-202
Learning Path(s): Product Management
LACE Explained: Roadmaps
An overview of the value, importance, and mechanics of Roadmaps at the Solution, Program, and PI levels.
In this course, you will gain an understanding of:
- The value of Roadmaps
- The 3 key components of Roadmaps
- The scope and characteristics of different Roadmaps
- The responsibilities of Stakeholders, Leadership, and Delivery Teams
Who should attend:
Program and Product Managers
- Duration: 1 hour
- Level: Intermediate
- Catalog Number: P-201
Learning Path(s): Product Management, Business Agility
LACE Explained: Social Contracts
Understand the necessity and power of team and program level Social Contracts in agile product delivery organizations.
In this course, you will gain an understanding of:
- The value of team level social contracts
- How to use Social Contracts for change management
- Differentiate the various program Social Contracts
- How Social Contracts work for Business Agility
- How Social Contracts create organizational accountability
Who should attend:
All program members
- Duration: 2 hours
- Level: Introductory
- Catalog Number: C-103
Learning Path(s): Agility Generalist, Scrum Master/Coaching, Business Agility
LACE Explained: Technical Agility
Ever wonder what the engineers are talking about? Interested in following the conversation and asking better questions? Attend this two hour session to demystify concepts such as Test Driven Development, the benefits of continuous integration, how automated tests work, and what are the techniques and practices that enable rapid, high quality, and successful agile software development.
In this course, you will gain an understanding of:
- The Importance of Agility Technical Practices
- Collaboration and Technical Practices
- What is Clean Code
- Continuous integration and agility technical practices
- Define Test First, Design Last
- How to manage technical debt
- Ways to measure software development
Who Should Attend:
Scrum Masters, Stakeholders on technical teams and anyone else that wants to increase their understanding of what makes agile software development successful.
- Duration: 2 hours
- Level: Introductory
- Catalog Number: F-106
Learning Path(s): Scrum Master/Coaching
LACE Explained: Value Stream Mapping
This is a two-hour course designed to provide participants with a basic understanding of the principles and concepts behind this powerful process improvement tool.
Participants will learn how to identify and analyze value streams, map current and future states, and develop implementation plans. The course will cover the basics of value stream mapping, including how to use this process maps to identify waste, how to analyze data to identify opportunities for improvement, and how to develop an implementation plan to optimize the value stream.
This course will also cover some of the common challenges that organizations face when implementing value stream mapping, such as resistance to change, and difficulties in data collection and analysis.
Participants will learn strategies for overcoming these challenges and ensuring successful implementation.
In this course, you will gain an understanding of:
- The benefits of organizing around value
- How to recognize different types of value streams
- The steps to map a value stream
- Methods to improve the flow of value
- Manage, maintain, and improve a value stream
Who should attend:
Anyone who wants to gain a basic understanding of value stream mapping, including process improvement professionals or anyone involved in optimizing business processes.
- Duration: 2 hours
- Level: Advanced
- Catalog Number: B-300
Learning Path(s): Business Agility