Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.




C O M M U N I T Y

Button Hyperlink
custom-iconradio
iconcustom
titleBack to Home
typestandard
urlLACE (CCSQ Lean Agile Center of Excellence)
Anchor
top
top




Horizontal Navigation Bar


Horizontal Navigation Bar Page
titleRESOURCES


Tabs Container
directionvertical


Tabs Page
titleAgile Roles

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.html

2 - Scaled Agile Framework (SAFe) https://www.scaledagileframework.com/

3 - Kanban https://www.atlassian.com/agile/kanban

FunctionRoleResponsibilitiesCeremonies to AttendOrganization
Business Owners

Business Owners 12 are a small group of stakeholders who have the primary business and technical responsibility for governance, compliance, and return on investment (ROI) for a Solution developed by an Agile Release Train (ART). They are key stakeholders on the ART who must evaluate fitness for use and actively participate in certain ART events.  

Stakeholder

Stakeholders provide the business problem to be solved and the value desired. They are the customer, or represent the customer,

  • Articulate Vision
  • Understand government mandates and their effect on the system
CMS
Solution Management Team

Solution 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.

  • Understand & articulate customer/policy needs
  • Understand government mandates and their effect on the system
  • Develop Solution Roadmap
  • Develop and communicate Solution Vision
  • Develop & accept Epics/Capabilities
  • Assist with Feature Development Elaboration
    • Help Product Managers develop features
  • Track Epics & Capabilities through Solution Kanban
  • Work with solution Architect to ensure proper system design
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.

  • Identify 

    Enablers 2
  • Participate in Continuous Exploration
  • Establish critical NFRs at the solution level
  • Take a "Systems View" of Architecture
  • Develop 

    Architectural Runway 6
CMS
Product Management
Anchor
PRODUCTMANAGEMENT
PRODUCTMANAGEMENT

Product 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.

  • Product Roadmap development
  • Develop & Accept Features
  • Prioritizing Product Work
  • Removing roadblocks
  • Release Planning & Coordination
  • Product Metrics
  • Tracks Product Kanban
  • Help Product Owners develop user stories
CMS

Program Support Team


Supporting the operations and execution of an Agile Release Train is a crucial role to create and release value. As such, Project Coordinators, Business Analysts, Project Managers, Program Analysts, Subject Matter Experts, etc. are invaluable members of the Program team to help keep the Program and Agile Release Train informed and aligned on Vision and Priorities. These are ART members that can stand in for Program members when they are unavailable and they are trusted advisors that represent the Program.


  • Support Product Managers
  • Write documentation
  • Coordinating activities within and across Programs
  • Understand & Communicate Non-Functional Requirements
  • Assist in product evaluation and compliance evaluation
  • Assesses solution risks and participates in risk management activities
  • Leverages a deep understanding of the product and program to assist program leadership proactively
  • Understand all the activities within the line of business (LOB) and ensure coordinated action among all programs and projects within and across LOBs
  • Collecting and aggregating program metrics
  • Gathers information from clients and contractors (ADOs) to create high-quality communications for stakeholders of the product



Non-ADO Support Contractors

Agile Release Train

The 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.

  • Manage and optimize the flow of value through the ART and Solution Train
  • Establish and communicate PI cadence, ceremonies
  • Facilitate PI Planning readiness by fostering the continuous exploration process
  • Facilitate the PI Planning event
  • Assist tracking the execution of features
  • Facilitate periodic synchronization meetings, including the Scrum of Scrums, or ART sync, at the Program level
  • Help manage risks, dependencies, and remove impediments
  • Work with Product and Solution Management, Product Owners, and other stakeholders to help ensure strategy and execution alignment

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.
  • Coach leadership
  • Coach RTEs
  • Coach teams
  • Provide formal SAFe training
  • Provide formal Agile training
  • Facilitate Communities of Practice
Non-ADO Support Contractors
Teams

Agile 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.

  • Develops User Stories & AC that implement established Features
  • Continuously refines the backlog and elaborates stories to support developer needs
  • Ordering the items in the Product Backlog to best achieve goals and missions
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next
  • Ensuring the Development Team understands items in the Product Backlog to the level needed

Application
Development Organization (ADO)

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.



  • Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible
  • Understanding product planning in an empirical environment
  • Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value
  • Facilitating Scrum events as requested or needed
  • Coaching the Development Team in self-organization and cross-functionality
  • Helping the Development Team to create high-value products
  • Removing impediments to the Development Team's progress
  • Facilitating Scrum events as requested or needed
  • Helping the team track metrics to foster continuous improvement
  • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood
  • Planning Scrum implementations within the organization
  • Helping employees and stakeholders understand and enact Scrum and empirical product development
  • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization
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.

  • They are  self-organizing 14. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog items into Increments of potentially releasable functionality
  • Development Teams are cross functional, with all the skills as a team necessary to create a product Increment
  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole
  • They collaborate with the Product Owner to create and refine user stories and acceptance criteria
  • Conduct research, design, prototyping and other exploration activities where required
Application
Development Organization (ADO)

References

1 - Scaled Agile Framework - Solution Management https://www.scaledagileframework.com/solution-management/

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



Tabs Page
titleWorking Agreement

LACE Social Contracts and Team Agreements: Working Agreement

We are committed to being there for our teammates

  1. Core Working  Hours: 10am-3pm
  2. When asked for help, immediately acknowledge the request and schedule time to assist 
  3. We will work in our collaboration space when not in meetings or in need of “Focus Time”
  4. We will have the courage to step out of our comfort zone to help with each others duties and responsibilities
  5. We will share our knowledge and pair work within the team to encourage growth/support

We promise to show each other respect, at all times

  1. Assume Positive Intent when dealing with other team members
  2. Speak from feelings (“I feel/felt like”) to move toward agreement and understand perspectives to avoid accusatory language
  3. Wait for others to finish speaking before responding
  4. We take time to recognize/celebrate accomplishments as a team.

We value the time of all team members​

  1. Be on time to all meetings or provide notice and expected deliverables if you will be absent
  2. Be fully engaged in meetings (no work or cell phones, cameras on in all meetings)

We hold ourselves to the highest standard of work

  1. We understand that our work quality reflects on every member of the team (LACE)
  2. All LACE members are familiar with trainings, playbook, and onboarding guide 
  3. All work is peer reviewed by one other team member 
  4. All coaching recommendations are in alignment with the playbook and the training
  5. When there is no guidance in the playbook and training discuss with team before providing recommendations. 

We will be a model for vulnerability and transparency in our organization

  1. Update your work on the board before daily stand-up
  2. Add outages to the team calendar
  3. Communicate outages in iteration planning
  4. Ask for help or peer reviews when needed
  5. We won't fear judgment/negative response keep us from being transparent 
  6. We welcome failure to encourage growth

We will prioritize continuous improvement above all other work

  1. Examine problems blamelessly
  2. Adapt Processes(mange Jira board, write user stories, etc.) for transparency and efficiency
  3. Honor retrospective commitments
  4. Update team contracts regularly
  5. Mistakes are an opportunity for improvement​


Tabs Page
titleDefinition of Ready

LACE Social Contracts and Team Agreements: Definition of Ready

We expect the Product Manager to use strategic vision to guide prioritization, planning, and delivery:

  1. The vision for all features has been presented to the team 
  2. The Product Manager will be fully available to the feature owner
  3. Work defined at the Feature level will be prioritized

We expect all team members to understand the value and context of all work being included in each iteration:

  1. The Feature Owner understands the vision and the expected outcomes of the feature
  2. The Feature Owner is prepared to clarify the requirements in refinement and/or planning
  3. The work defined contains a value statement (who, what, why) (benefit hypothesis or use story statement)
  4. The work defined contains clear acceptance criteria that can be verified as pass/fail (success or acceptance criteria)
  5. The work defined will fit into the appropriate timebox
We will only make commitments for work that meets our standards of Ready

For each work item, before commitment:

  1. The work is prioritized
  2. The correct issue type is used
  3. If necessary or beneficial to cross-functionality, Mob/Pair team members are identified
  4. Peer review rigor and significant time commitments for peer review are defined and noted in the work item**
  5. All team members delivering have been added to a role
  6. There is an estimate
  7. Labels are accurate
  8. Links are accurate (clones, features, dependencies, etc)

We refuse to allow low quality requirements to impact our reliability.

  1. The value is clear and understood (Why?)
  2. The desired outcome is clear (What?)
  3. The user/persona/beneficiary is defined and is the recipient of the value delivered (Who?)
  4. Binary acceptance criteria are present
  5. Relevant guidance, information, and documentation links are included
  6. Potential risks, blockers, unknowns, and dependencies​ are noted
  7. Defects are clearly defined with:
    1. Steps to reproduce​
    2. Expected results​
    3. Screenshots/logs​
    4. Test data

Reference for Feature

The Feature can be clearly described.

The feature is well enough understood that its extent and purpose can be clearly explained by the Product Management / Product Ownership Team

Small enough to fit within a PIThe estimates for the Feature indicate that it is small enough to be easily completed within a standard Program Increment (PI).
The Feature is testableThe need for any unusual or novel testing is clear and factored into the estimates
The Feature is feasibleFor Business Features the architectural and technical risks are under control and it is expected that the Feature can be implemented without any significant technical issues. For experimental enablers and spikes the constraints are understood and the financial exposure is in-line with the probability of success.
The potential benefits are understoodThe Feature has a well understood, measurable benefits hypothesis.
The Feature has a clear ownerIt is clear who the team pulling the Feature should converse, and negotiate with, over the scope and extent of the Feature, and who will accept the Feature as done.
The level of key stakeholder involvement is understood.The details of any important external Stakeholders are known and the mechanisms to involve them in a timely way have been put in place.
The cost of delay is clearThe relative business / user value, time criticality, risk reduction and opportunity enablement are well enough understood that the Features cost of delay is clear. See the SAFe approach to Weighted Shortest Job First for more details.
Any ‘fixed’ requirements are knownAny specific, fixed, non-negotiable aspects of the Feature are known and their details are available. For example the specific actuarial calculations to be used in an insurance system.



Tabs Page
titleDefinition of Done

LACE Social Contracts and Team Agreements: Definition of Done

We prioritize delivering value to customers, which is our organizations highest priority

  1. We can demonstrate completed work to our customers and stakeholders

  2. We will respond to feedback to make the work we do more valuable

  3. Features are only complete when our business owners agree the value has been delivered

We believe that Quality is of the utmost importance

  1. Each Acceptance criteria has been met

  2. The work meets the goal of the user story

  3. All work is peer reviewed

  4. The status of the work item to “Done”

We believe that our work should be accessible to the community

  1. We will post all assets produced in confluence, for the benefit of the CCSQ Community or our stakeholders

  2. We will present similar content in a visually consistent manner, both visually and in a way the content is accessed

Example Definition of Done for product and service delivery teams:

We promise the organization that we will uphold all technical standards

  1. Ensure all enterprise policies are observed

  2. Ensure all enterprise standards are met

  3. Ensure all organizational standards are met

  4. Ensure all team standards are met

We understand the value and importance of meeting non-functional requirements

  1. All work will be 508/screen reader compliant

  2. All work will meet security standards

  3. All applicable design library components are used

  4. All UI/UX guidelines are followed

We will develop sustainable code for the benefit of the organization

  1. Names for objects, classes and functions are human readable

  2. The code contains lean but descriptive comments

We believe that Code Quality is of the utmost importance

  1. Unit Tests coverage is XX%

  2. Code is peer reviewed

  3. Integration tests are included

  4. The code builds successfully into the integrated solution

We prioritize delivering value to customers, which is our organizations highest priority

  1. Each Acceptance criteria has been met

  2. The work meets the goal of the user story

We acknowledge that we cannot decide when work is complete without stakeholders

  1. The work has been demonstrated to the Product Owner

  2. The Product Owner has changed the status of the work item to “Done”


Tabs Page
titlePI Planning Board

CCSQ PI Planning Board

The LACE has enhanced the LucidSpark PI Planning template to support the way CCSQ Programs plan. All enhancements are noted under the images.

In Lucid, go to Templates → Search for 'CCSQ PI Planning Template' → Click on the Template and select Use Template.

Quick Setup Instructions:

Rapid setup and Jira import instructions
Notes explaining each area (Icon for notes outlined in red)










Team Planning Area Enhancements:

Team Backlog Import area
6 Iteration planning increment
PI Objectives area
Capacity and load cards for each iteration

Program Planning Area Enhancements:

Program Backlog Import Area
6 Iteration Program Board
Shared Services Swimlane
Identified Program Risks Area

Planning Activities Enhancements:

Planning Retrospective Board



Tabs Page
titlePI Planning Supplies

PI Planning Supplies: Calculator & Checklist 

Download the Excel document here.


Tabs Page
titleScaled Agile Framework

Scaled Agile Framework

SAFe is an online and “freely-revealed knowledge base of proven success patterns for implementing lean-agile software and systems development at enterprise scale.” SAFe provides ceremonies, roles, metrics, and relationships that allow organizations to leverage lean and agile at enterprise scale.

Scaling Agile with Atlassian and SAFe White Paper:

 PDF

A Case Study of CMS Implementation of SAFe:

What's New in SAFe 6.0 (SAFe Website):

What's New in SAFe 6.0 (Video):

Widget Connector
urlhttps://www.youtube.com/watch?v=PWfCvSUBnHE&t=7s




Tabs Page
titlePsych Safety Team Exercises

Psychological Safety Team Exercises

The exercises here can be facilitated by a member of the LACE team by request, or a team member can facilitate using them the exercise instructions.

Tabs Container
directionhorizontal


Tabs Page
titlePsychological Safety

Psychological Safety

Think of a time at work, at any point in your career, in which you held back on speaking up with a potentially important work-related idea, question, or concern. Think of who was present, what was being discussed. What did you momentarily consider saying?

•     What was the primary cause of your withholding?
•     What was the primary consequence of your holding back?

To what extent do these statements hold true in your workplace?

•     In my company, I feel empowered to take risks.
•     My organization has a healthy mindset around failure.
•     Hitting your targets is the only way to get ahead.

Think of a recent failure at work that you observed or helped create.

•     What was the context? (Where did it happen?/What was the goal?)
•     What were the primary causes of the failure?
•     Who knew about it?
•     How much was learned from the failure?

Recall the failure you identified earlier.

•     Consider the context and the primary causes of the failure.
•     How would you characterize the context?
•     Routine
•     Complex/Customized/Variable
•     Innovation/Discovery

What percent of failures in your organization are caused by blameworthy acts?
What percent of failures in your organization get treated as if caused by blameworthy acts?
How might you, “frame the work” keeping the following features of the work in mind: uncertainty, interdependence, what’s at stake, the role of failure?
What will you say to build a shared understanding that anyone’s voice might matter?
What good questions can you ask in your next meeting?
When should you push for breadth? When should you probe for depth?


Tabs Page
titleTension Session

Tension Session 

Normalize productive conflict on your team by using an exercise to map out the unique value of each role and the tensions that should exist among them. Teach that conflict and tensions are not the antithesis of cross-functional teams, but part of high performance and continuous improvement.

Activity Instructions:
  1. Draw a circle and divide that circle into enough wedges to represent each role on your team. For each role, ask:
    1. What is the most common tension this role puts on team discussions? What one thing does the person in this role have to say that frequently makes others bristle?
    2. What is the unique value of this role on this team? What should this person be paying attention to that no one else is? What would we miss if this role wasn’t here?
    3. On which stakeholders is this role focused? Whom does it serve? Who defines success?
  2. Answer those questions for each member of the team, filling in the wedges with the answers.
Facilitator Notes: 
  • Emphasize how the different roles are supposed to be in tension with one another throughout
  • Use examples of contentious issues that your team has been stuck on to illustrate these points.
  • Talk about how you’ll use each of these different perspectives as criteria in your decision making from now on.

Once you go through this exercise, you’ll see that  when presented with all the information, the team will be able to align around a decision. Where they can’t, the most effective path is to defer to the team leader to make a call taking all of the perspectives into consideration.

What you’ll discover using this exercise will open up so many great discussions. Use it to address issues like:

  1. someone who is advocating too hard for their narrow point of view
  2. a team member who has stopped adding their unique value and as a result has left the team exposed in some way
  3. A role imbalance on a team where role coalition overpowers other roles
  4. Performance goals that are misaligned with the best interests of the team overall.

With heightened awareness and a shared language, your team will start to realize that much of what they have been interpreting as interpersonal friction has actually been perfectly healthy role-based tension. They’ll realize that ; they’re one of the main benefits of them. (Or as I like to put it, conflict is a feature, not a bug on teams.)


Tabs Page
titleAnxiety Party

Anxiety Party

This exercise helps teams to practice vulnerability honesty, and encourages them to acknowledge their own insecurities. It also surfaces conversation and alignment on projects, products and priorities. It was originated by Google Ventures n 

Activity Instructions:
  1. Ask your team to write down their biggest anxieties
  2. Have everyone rank their concerns in order from most to least worrisome
  3. Have a team member share their list with the team
  4. Ask other team members if they had similar anxieties.
  5. Facilitate a conversation to get feedback and perspective 




Tabs Page
titleContinued Learning

Continued Learning: Self-Study Recommendations

Varieties of Agile:

Scrum: https://www.scrum.org/ 

Lean: https://www.lean.org/

Feature-Driven Development: http://www.agilemodeling.com/essays/fdd.htm

Extreme Programming (XP): http://www.extremeprogramming.org/

Scaling Agile:

Scaled Agile Framework (SAFe): http://www.scaledagileframework.com/

Large Scale Scrum (LeSS): https://less.works/

Nexus: https://www.scrum.org/resources/scaling-scrum

Disciplined Agile (DA) Framework: http://www.disciplinedagiledelivery.com/


Other Helpful Links:

Agile Manifesto: http://agilemanifesto.org/

Center of Enterprise Agility (CEA): https://share.cms.gov/cms-wide/governance/Agile/SitePages/LandingPage.aspx (CMS Employees Only)


Videos:



Widget Connector
urlhttps://www.youtube.com/watch?v=x8jdx-lf2Dw


Widget Connector
urlhttps://www.youtube.com/watch?v=2NFH3VC6LNs&t=1s





Horizontal Navigation Bar Page
titleCOMMUNITY EVENTS


Tabs Container
directionvertical
Tabs Page
titleDecember 2023

December 2023 Using AI To Increase Productivity

Wednesday, December 6th from 1:00pm-3:00pm EST

CCSQ LACE Community of Practice: Using AI To Increase Productivity

Join us, for an enlightening session exploring the cutting-edge world of Artificial Intelligence (AI). This LACE Community Event is dedicated to unveiling the potential of AI tools and how they can revolutionize workflows, decision-making, and information management within the CCSQ community.

Attendees will engage with:

  • AI tools showcase
  • Recent updates on AI
  • Practical applications in your daily responsibilities

Agenda:

Look for more information soon!

Session Resources: 

More information to come!


Tabs Page
titleSeptember 2023

September 2023 Empowering Business Agility

Wednesday, September 6th from 1:00pm-3:00pm EST

CCSQ LACE Community of Practice: Empowering Business Agility 


During this CCSQ Community of Practice event, the LACE will explore the boundless possibilities of embracing agility to enhance our organizations' resilience and success. Together, we unlock the potential of adaptive strategies, foster a culture of continuous improvement, and build strong connections to thrive in an ever-changing business landscape.


Attendees will:

  • Discover what Business Agility is,
  • Learn about the state of Business Agility in CCSQ,
  • Gain insight from SAFe and
  • Hear from speakers’ firsthand experiences.

Agenda:

Look for more information soon!

Session Resources: 

More information to come after the event!

What's Coming Up: 

TBA



Submit Feedback on the Event! Be Honest. (We can take it, we swear)


comment Submit Feedback Here


Tabs Page
titleJune 2023

June 2023 Creating Organizational Accountability

About the Session: 

LACE facilitated a conversation between attendees and speaker, Mindy Riley, Supervisory IT Specialist, QPP, to examine the various agreements between teams, leadership, customers and partners to create a fabric of organizational accountability.

During the Community of Practice, the LACE discussed:

  • How continuous exploration fuels innovation,
  • Guidance and tools needed to work effectively in remote environments with distributed teams, and
  • Creating a defined vision, strategy, and roadmap to satisfy existing customers and attract new ones.

Agenda:

Introduction

  • Zoom Poll and Welcome Participants

Keynote: Mindy Riley – Beyond SAFe: Program Transparency and Accountability

  • Keynote Discussion

Tacit Agreements + Discussions 

Persistent Agreements 

  • Social Contracts video

Break (10 Minutes)

Completion Agreements + Discussions

Commitments + Discussions 

The Funnel of Accountability 

Discussions: Improving Accountability  

Session Resources: 

Submit Feedback on the Event! Be Honest. (We can take it, we swear)

>>

comment Submit Feedback Here


Tabs Page
titleFebruary 2023

February 2023 Measuring the Enterprise

About the Session: 

During this Community of Practice, LACE explored Measuring the Enterprise with a variety of metrics.
Attendees learned: 

  • From members of the CCSQ community discussing how they utilize metrics to identify improvement opportunities,

  • Participated in lightning talks,

  • Interacted and shared knowledge across CCSQ,

  • How metrics can help you with visibility and continuous improvement to reduce variability and increase predictability.

Session Lightning Talks:

  • Using Metrics to Improve Delivery Flow & Reduce Wait
    • Presented by: Joshua Skillington, Scrum Master, Manager, ICF
  • Metrics Create the Space for Innovation
    • Presented by: Prashamsa Muppavaram, Release Train Engineer, iQIES
  • A Human-Centered Approach to Customer Satisfaction
    • Presented by: Rhiannon Hill & Patrick Dahlen, Sr. Director & Sr. Manager, CCSQ Service Center, Ventech
  • Qualia to Quantity
    • Presented by: Howard Montgomery, Sr. Strategist, CCSQ HCD Center of Excellence
  • Enterprise Dashboards
    • Presented by: Seth Evans, Agile Coach, CCSQ Lean-Agile Center of Excellence
  • Better Quality of Service Data Reduces Support Costs
    • Presented by: Justyna Sardin, EQRS Product Manager, CMS
  • Monitoring and Mitigating System Impacts
    • Presented by: Greg Evanitsky, Atlassian System Administrator, Enterprise Services, Ventera 

Session Resources: 


Tabs Page
titleNovember 2022

November 2022 Psychological Safety


What is Psychological Safety?

Psychological Safety is a shared belief held by members of a team that others on the team will not embarrass, reject, or punish them for theirideas and contributions. 

Establishing a psychologically safe environment in your teams and programs is critical to reach the highest level of team performance an output.  How does Psychological Safety impact organizational performance? What are the economic impacts Psychological Safety? How can we help create Psychological Safety in our teams and programs?

Come to this highly interactive Community of Practice to understand how psychological safety is intrinsically tied to performance, how to conduct conversations in a way that rewards contributions, and identify behaviors that increase or reduce the productivity of your team or program.

Agenda:

1:00 - 1:25 PM:  What is Psychological Safety? - Information Session
1:25 - 1:40 PM:  Advice from a Mentor - Breakout Activity
1:40 - 1:55 PM:  Fostering Psychological Safety - Information Session
1:55 - 2:05 PM:  Break
2:05 - 2:15 PM:  Fostering Psychological Safety (cont'd) - Information Session
2:15 - 2:45 PM:  Blameless Problem Solving - Breakout Activity
2:55 - 3:00 PM:  Follow up Information and General Announcements

The Psychological Safety Team Exercises can be found under the "Resources" tab.




Horizontal Navigation Bar Page
titleTOOLKITS & TEMPLATES


Tabs Container
directionvertical


Tabs Page
titleEffectiveness in the Remote Workplace

Effectiveness in the Remote Workplace



Rules of Thumb For Working From Home

Create a Work Space 

Creating a work space in your home helps you context switch been work and life. Try to create a space that is out of the main flow of traffic in your house. If you can't, make sure you have a comfortable headset so you can "tune out" the activity of your household. Use a background in your online meetings to keep the activity in your household from being a distraction for others during meetings

Have a Routine

Just like when going into the office, you should try to maintain a routine. Healthy routines provide us with structure. Often, people new to work from home will find their sleep and meal schedules thrown off. Build time into your day to get up and stretch, take a walk, eat, and socialize with co-workers.

Create a Daily Work Plan

When we work from home we are more self-guided. Start your day by identifying the highest priority work you have for the day, and use a simple tool to track your work. Make sure you account for the meetings you have and the parts of your routine that aren't "hands on keyboard"

"Get Ready" for Work

Make the first part of your daily routine getting ready for work. This will help you context switch from being at home to being at work. Plus, you'll feel better. I swear.

Set Good Boundaries

People who are new to working from home tend to work far more than they do when going to the office. When you did go to the office, how many times each evening did you think or talk about a work problem? It's much harder to not act on that when your work space is in your home. You may have to more rigorous to create that separation by turning off notifications on your phone at a certain time every day.


Tips, for a healthy work from home/life balance

Create Social Spaces

We are social creatures. Even the most introverted people need some social interaction. We often don't realize how socializing with our colleagues and friends at work satisfies those needs, until we work from home. Create some online social spaces to spend time with your colleagues outside of a work context. Join a video call and have lunch. Join a virtual happy hour and blow off some steam with your co-workers.

Do Something New

Pick up a new hobby. Read more. Take Online Courses For Free.  Write a blog. Do a podcast. Plant a garden. Find ways to replace the time that you used to spend meeting with friends, shopping, hitting the gym, eating out, etc with something new. Filling your free time will make keeping a good work/life balance easier.

Get some exercise

Staying at home can mean a mean a more sedentary lifestyle. Walking around the office to ask questions and have quick discussion, going to the bathroom, the printer and recycling bins adds in terms of physical activity. Ask anyone who counts steps. Take walks to start working out. Keep your metabolism healthy

Maintain your Boundaries

Maintaining the boundaries you set. Post working hours for your family. Don't get sucked into 1 hour conversations at 5:30 PM. Hold yourself to your scheduled social time with colleagues during work.

Find the Positives

Once you've worked from home for a month, you may realize a few things:

  • How ridiculous all those meetings were
  • How bad your organization's communication was
  • How chat is an effective and efficient way to get similar results to a meeting.
  • How incredibly inefficient it is to commute in rush hour traffic twice a day
  • How much time we weren't working during work hours
  • How it’s no longer as necessary to live in an expensive city
  • How difficult it is to concentrate at home when you have kids or a stay at home spouse
  • How lonely working from home can be
  • How much more productive you are


Tabs Page
titleBest Practices for Virtual Collaboration

Best Practices for Virtual Collaboration














Remote Working Agreements

In order to be successful in a fully remote or hybrid context, the working agreement must be updated to account for the nuances of digital interactions.

Because working remotely is something new for your team, the working agreement should be reviewed every iteration as the team's practices evolve and new challenges and solutions are discovered. As with all working agreements the team must hold themselves and their teammates accountable for upholding the behaviors of the agreement.

Face-to-face communication is a key component of team function. Audio and video technology simulate this experience but only when all participants are engaged and committed to using the tools in these ways:
  • All users need to have webcams. To simulate co-located work environments, we need to see each other.
  • Create a persistent team room with video services. Team members who are on-line and working should be in the team room.
  • Camera's should always be on in the team room. For those not comfortable with being on camera, aim the camera so that it shows the top of your head. Just like in the office, people should be able to look to know if you are there or not. 
  • Simulating face-to-face means hearing the conversations you can add value to and joining in. If there is a lively conversation that you are not participating in, let the team know you're "going on mute". If you are Scrum Master, move lively conversations to a breakout  room or online meeting.
  • Let your teammates or Scrum Master know if you are "leaving the team room" to go to a virtual meeting.
  • Manage statuses and calendars accurately. Ensure your calendar is shared with your team members and those in your product and organizational pipelines. If you are away, create out of office notifications and set your chat status to away. If someone needs you urgently, they should contact your Scrum Master
  • Manage work item status and ownership. Don't make people ask what the status of your work items are. Use your organizations tools to make that information "Always Available". 

 See Work Item Management Best Practices in Toolkits & Templates.


Tabs Page
titleWork Item Management Best Practices

Work Item Management Best Practices 

Whoever owns it manages the status, and whoever is currently is working it owns it.

Because work item status management is the responsibility of the owner, the transfer of ownership throughout the process is key for both communications and visibility. As a result the statuses that a specific owner can manage are limited to those within their domain authority. For example, a developer has authority to say a work item is in “development” or “ready for testing”, but changing a work item’s status to complete is outside their domain authority.

Please note that the Scrum Master is empowered to manage status or ownership on all work items, based on the self-organization principles of the team, but should rarely, if ever, own a work item that is not a retrospective commitment.

Ownership is “taken”, not given

Scrum leverages KanBan’s operating model. Members of a development teams “pull” work from the prioritized sprint backlog in priority order. Since we can’t predict who will be ready to pull the highest priority item the highest priority item from the sprint backlog next, the onus of changing ownership is on the person beginning the next phase of work. The exception to this general rule is that work is pushed into the "Ready For" states

Lead Time Vs Cycle Time

In order to support enterprise metrics, no statuses should be mapped to "In Progress" until development work begins

Recommended Story States and Definitions

New:

Has been created and can be in any state of refinement by the Product Owner and/or team, but has not met the definition of ready

To-do

Ready:

Has met the team’s Definition of Ready but has not been taken into an iteration commitment

To-do

In Development:

A developer has become available, taken ownership of the story and begun working on a task associated with the story

In Progress
Ready for ReviewThe developer has completed the story and needs it reviewed by a fellow engineerIn Progress
In Peer ReviewA fellow engineer is reviewing and discussing with the authoring engineer if/when changes need to be madeIn Progress

Ready for Test:

All development tasks are complete, the code has been reviewed, integrated, and deployed to the test environment.

In Progress

Testing:

Testing of the story has begun, test cases are being run against all business, functional an non-functional requirementsIn Progress

Ready For Acceptance:

Testing is complete, and the story is awaiting the product owner to begin validating the Business and Functional requirements defined in the Acceptance Criteria

In Progress

Complete:

The Product Owner has validated the Acceptance Criteria and approves the story for deployment

Done

Abandoned:

The Product Owner has made the decision that the story is no longer necessary

Done

User Story Ownership

The user stories are owned by the product owner, from the time created until a developer “takes” the story and begins to work on it. This developer “owns” the story until the story is picked up by a tester. The tester owns the story until the product owner takes the user story back for acceptance. For User stories where task assignment is split(not recommended and is usually and indicator that story size is too large) Ownership should be assumed by the first person taking a task, and can be updated to the person working the last open task.

Ownership Role

Status

Status Change

Product Owner

New

Ready

Developer

Ready

In Development

Developer 1

Development

Ready for Peer Review

Developer 2Peer ReviewReady for Test,  Development

Tester

Testing

In Development, Ready for Acceptance

Product Owner

Ready for Acceptance

Complete

Product Owner

<any state>

Abandoned*

*Only the Product Owner or Scrum Master have the authority to abandon a story

 Recommended Task/Story States and Definitions for KanBan Teams

To do:

A task/story has been created and is in the backlog

To-DoTo-Do

In-Progress:

A task/story has been started by an engineer

In ProgressIn Progress
Awaiting ReviewA task/story is ready for review by another engineerIn In ProgressProgress
In ReviewA task/story is being reviewed internallyIn ProgressIn Progress

Awaiting Awaiting Validation

The task/story is awaiting confirmation of completion

In ProgressIn Progress

Complete:

The task meets the release criteria defined in the team's definition of done

DoneDone

Abandoned:

The team has made the decision that the task is no longer necessary.

DoneDone



Tabs Page
titleCommunication & Remote Collaboration

Communication & Remote Collaboration

The Golden Rule: Always Assume Positive Intent

We lose  layers of subconscious  information, even with video on. When  working remotely,  we must ALWAYS assume positive intent until we confirm otherwise. If something seems harsh, say  it back to yourself as a valley girl or a curious child.

Written Communication

  • Strive for Clarity: In email and chat, present digestible chunks of information and surface main points as a bullet/numbered list.  
  • Strive for Brevity: Before you send, try to rewrite with 30 percent less words.
  • Strive for Directness:  Respond directly to the question being asked
  • Ask for confirmation: When communicating critical or nuanced information, ask if clarification is needed.
  • Slow Down: Be sure others are finished speaking. When working in a distributed team, make sure we aren't experiencing a technology-based communications lag. When speaking, leave time for questions between statements.

Visual Communication

  • Radiate information: Use the tools at your disposal to keep everyone apprised of your progress and status
  • Collaborate: Use the tools you can to collaborate and team build.
  • Be Visible: Ensure others know if and when you are available.
  • Replicate the Shared Work space: Use the tools and technology to function as much like a team in a shared work space as possible

Verbal Communication

  • Slow Down: Be sure others are finished speaking. When working in a distributed team, make sure we aren't experiencing a technology-based communications lag. When speaking, leave time for questions between statements.

  • Be inclusive: Solicit the opinions of people who are uncomfortable or not engaged.

  • Strive for Clarity of Intent: Express if you are stating a question, opinion or a fact. When expressing an opinion, use statements that start with "I believe that", "I think that", or "In my opinion", or other similar phrases for opinions. For facts, try statements like "The current state of the system", "I have verified that", "This was confirmed by", or "I am not sure if".
  • Strive for Brevity: Think about what you want to say before you say it. Make sure your intent is clear and easily understood. Make your main point in the first sentence, then support it with a few more if needed. Then, pause and wait for questions.
  • Strive for Directness: Make sure to answer the question being asked or speak directly to the issue. 
  • Ask for confirmation: After you finish communicating critical or nuanced information, ask if everyone understands what was said. Listen for uncertainty
  • Listen for Uncertainty: Actively listen for verbal cues that tell us if someone understands or agrees or not.

Procedural Communication

  • Manage Your Work: Keep status and ownership of work items up to date. (see: See Work Item Management Best Practices in the Toolkits & Templates)

Team Building Resources:


Tabs Page
titleHow to Use Zoom Meetings

How to Use Zoom Meetings

How To:

Description:
Sign Up & DownloadingZoom 101 Sign Up & Download Meeting Client
Joining a MeetingJoining a Zoom meeting is quick and easy! Discover the options for joining meetings based on your requirements and to ensure the best meeting experience possible.

Get a quick introduction to the basic meeting controls available on Zoom calls.

Sharing Your ScreenThis video covers screen sharing and related Zoom collaboration tools.



Tabs Page
titleRemote Collaboration Software & Tools

Remote Collaboration Software & Tools

Currently Approved for use in the CCSQ Virtual Workplace:

External Tools:

The tools below may help your team adapt to a remote context if needed. Free versions are reflected below, as pricing model are currently understood. If you encounter a mistake, please let us know. 

Planning Poker
Retrospective
Story mapping, white boarding, and other collaboration tools

Some tools will need to be approved by the Technical Direction Board. Approved tools may have associated licensing costs and will need approval to purchase from your organization.



Tabs Page
titleRemote PI Planning


Tabs Page
titleRemote PI Planning

Remote PI Planning

Recommendations and templates for conducting team events that will occur at multiple locations simultaneously through online collaboration tools and audio and video communication among sites

Online Tutorials:

Downloadable Templates:

Team Breakout Virtual Boards (click to download Excel file)
ART Remote Checklists (click to download Zip file)

Event Support Request: 

https://bit.ly/2UecirU


PI Planning Agenda:

Day 1

Time

Topic

Description

Key People

Comments/Additional Information

8:30 -8:45

“Arrive” and get settled in

ART Members will log in to the selected Zoom session

All ART Members


8:45 – 9:00

PI Welcome & Working Agreements

Zoom Session with presented slide deck (RTE)



9:00 – 9:15

Presentation

Zoom Session with presented slide deck (RTE)



9:15 – 9:45

Architectural Review

Zoom Session with presented slide deck (RTE)



9:45 – 10:00

Top Priorities / Themes for PI

Zoom Session with presented slide deck (RTE)



10:00 – 10:30

Planning Context

Zoom Session with presented slide deck (RTE)



10:30 – 3:15

Team Breakouts

Teams will disperse into Zoom breakout rooms. Program Board and Iteration Boards will be posted in a shared Mural page.



  • A dedicated operator will be on hand (PM3) to facilitate  movement from breakout room to breakout room from the lobby/main session.

 


  • Users assigned to a breakout room will have the ability to move between the breakout room and main session at will but will need operator assistance to enter a breakout room to which they were not previously
  • Teams will determine for themselves when they would like to take a lunch break during this time.
  • Slack will be available for inter-team non-verbal communication.
  • All key information radiators will be available in a single Mural page; users will simply have to zoom in/out to view the artifact of their choosing.

3:15 – 4:15

Draft Plan Review


Zoom Session with RTE presenting Mural page and Confluence page with Teams’ Draft Objectives

All ART Members


4:30 –  5:30

Management Review and Problem Solving

Separate Zoom Session with RTE presenting Mural page


By invite only



Day 2

Time

Agenda Topic

Description

Key People

Comments/Additional Info

8:30 -8:45

“Arrive” and get settled in

ART Members will log into the selected Zoom session



8:45 –  9:30

Planning Adjustments

Zoom Session with RTE presenting Mural page

All ART Members


9:30 – 1:00

Team Breakout Sessions

Teams will disperse into Zoom breakout rooms, Program Board and Iteration Boards will be posted in a shared Mural page. Slack will be available for inter-team non-verbal communication.



  • A dedicated operator will be on hand (PM3) to facilitate movement from breakout room to breakout room from the lobby/main session.

 


  • Users assigned to a breakout room will have the ability to move between the breakout room and main session at will but will need operator assistance to enter a breakout room to which they were not previously
  • Teams will determine for themselves when they would like to take a lunch break during this time.
  • Slack will be available for inter-team non-verbal communication.
  • All key information radiators will be available in a single Mural page; users will simply have to zoom in/out to view the artifact of their choosing.

1:00 – 3:15

Final Plan Review and Program Risks

Zoom Session with RTE presenting Mural page and Confluence page with Teams’ Final Objectives

  • Product Owners
  • Business Owners


3:15 – 3:30

Confidence Votes

Teams will anonymously up vote a 1-5 card on FunRetro



Example: https://funretro.io/publicboard/244SPxASLkdKFaODx3yS2A7f3Hm2/7e3d1777-1c7b-4168-a611-8fb03a371ec6

3:45 – 4:30

Plan Re-work

Teams will disperse into Zoom breakout rooms, Program Board and Iteration Boards will be posted in a shared Mural page; Zoom Operator will be on hand to facilitate inter-room movement


Optional

4:30 –

5:00

Planning Retrospective & Moving Forward

Zoom Session with RTE presenting Mural page













Include Page
UPDATE FOOTER HERE
UPDATE FOOTER HERE


Button Hyperlink
custom-iconarrow-up-circle
iconcustom
titleBack to Top
typestandard
url#top


Excerpt Include
UPDATE HTML HERE
UPDATE HTML HERE
nopaneltrue

HTML
<style> 
.aui-tabs.vertical-tabs>.tabs-menu {width:300px;)

</style>