- Created by Jessica Schultz, last modified by Meaghan Hudak on Aug 08, 2024
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 22 Current »
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
Function | Role | Responsibilities | Ceremonies to Attend | Organization |
---|---|---|---|---|
Business OwnersBusiness 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, |
| 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 SupportAt 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. |
|
| 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
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
LACE Social Contracts and Team Agreements: Working Agreement
We are committed to being there for our teammates
- Core Working Hours: 10am-3pm
- When asked for help, immediately acknowledge the request and schedule time to assist
- We will work in our collaboration space when not in meetings or in need of “Focus Time”
- We will have the courage to step out of our comfort zone to help with each others duties and responsibilities
- 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
- Assume Positive Intent when dealing with other team members
- Speak from feelings (“I feel/felt like”) to move toward agreement and understand perspectives to avoid accusatory language
- Wait for others to finish speaking before responding
- We take time to recognize/celebrate accomplishments as a team.
We value the time of all team members
- Be on time to all meetings or provide notice and expected deliverables if you will be absent
- Be fully engaged in meetings (no work or cell phones, cameras on in all meetings)
We hold ourselves to the highest standard of work
- We understand that our work quality reflects on every member of the team (LACE)
- All LACE members are familiar with trainings, playbook, and onboarding guide
- All work is peer reviewed by one other team member
- All coaching recommendations are in alignment with the playbook and the training
- 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
- Update your work on the board before daily stand-up
- Add outages to the team calendar
- Communicate outages in iteration planning
- Ask for help or peer reviews when needed
- We won't fear judgment/negative response keep us from being transparent
- We welcome failure to encourage growth
We will prioritize continuous improvement above all other work
- Examine problems blamelessly
- Adapt Processes(mange Jira board, write user stories, etc.) for transparency and efficiency
- Honor retrospective commitments
- Update team contracts regularly
- Mistakes are an opportunity for improvement
LACE Social Contracts and Team Agreements: Definition of Ready
We expect the Product Manager to use strategic vision to guide prioritization, planning, and delivery:
- The vision for all features has been presented to the team
- The Product Manager will be fully available to the feature owner
- 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:
- The Feature Owner understands the vision and the expected outcomes of the feature
- The Feature Owner is prepared to clarify the requirements in refinement and/or planning
- The work defined contains a value statement (who, what, why) (benefit hypothesis or use story statement)
- The work defined contains clear acceptance criteria that can be verified as pass/fail (success or acceptance criteria)
- 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:
- The work is prioritized
- The correct issue type is used
- If necessary or beneficial to cross-functionality, Mob/Pair team members are identified
- Peer review rigor and significant time commitments for peer review are defined and noted in the work item**
- All team members delivering have been added to a role
- There is an estimate
- Labels are accurate
- Links are accurate (clones, features, dependencies, etc)
We refuse to allow low quality requirements to impact our reliability.
- The value is clear and understood (Why?)
- The desired outcome is clear (What?)
- The user/persona/beneficiary is defined and is the recipient of the value delivered (Who?)
- Binary acceptance criteria are present
- Relevant guidance, information, and documentation links are included
- Potential risks, blockers, unknowns, and dependencies are noted
- Defects are clearly defined with:
- Steps to reproduce
- Expected results
- Screenshots/logs
- 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 PI | The estimates for the Feature indicate that it is small enough to be easily completed within a standard Program Increment (PI). |
The Feature is testable | The need for any unusual or novel testing is clear and factored into the estimates |
The Feature is feasible | For 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 understood | The Feature has a well understood, measurable benefits hypothesis. |
The Feature has a clear owner | It 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 clear | The 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 known | Any 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. |
LACE Social Contracts and Team Agreements: Definition of Done
We prioritize delivering value to customers, which is our organizations highest priority
We can demonstrate completed work to our customers and stakeholders
We will respond to feedback to make the work we do more valuable
Features are only complete when our business owners agree the value has been delivered
We believe that Quality is of the utmost importance
Each Acceptance criteria has been met
The work meets the goal of the user story
All work is peer reviewed
The status of the work item to “Done”
We believe that our work should be accessible to the community
We will post all assets produced in confluence, for the benefit of the CCSQ Community or our stakeholders
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
Ensure all enterprise policies are observed
Ensure all enterprise standards are met
Ensure all organizational standards are met
Ensure all team standards are met
We understand the value and importance of meeting non-functional requirements
All work will be 508/screen reader compliant
All work will meet security standards
All applicable design library components are used
All UI/UX guidelines are followed
We will develop sustainable code for the benefit of the organization
Names for objects, classes and functions are human readable
The code contains lean but descriptive comments
We believe that Code Quality is of the utmost importance
Unit Tests coverage is XX%
Code is peer reviewed
Integration tests are included
The code builds successfully into the integrated solution
We prioritize delivering value to customers, which is our organizations highest priority
Each Acceptance criteria has been met
The work meets the goal of the user story
We acknowledge that we cannot decide when work is complete without stakeholders
The work has been demonstrated to the Product Owner
The Product Owner has changed the status of the work item to “Done”
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
PI Planning Supplies: Calculator & Checklist
Download the Excel document here.
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:
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):
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.
Psychological Safety Team Audit
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?
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:
- Draw a circle and divide that circle into enough wedges to represent each role on your team. For each role, ask:
- 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?
- 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?
- On which stakeholders is this role focused? Whom does it serve? Who defines success?
- 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:
- someone who is advocating too hard for their narrow point of view
- a team member who has stopped adding their unique value and as a result has left the team exposed in some way
- A role imbalance on a team where role coalition overpowers other roles
- 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.)
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:
- Ask your team to write down their biggest anxieties
- Have everyone rank their concerns in order from most to least worrisome
- Have a team member share their list with the team
- Ask other team members if they had similar anxieties.
- Facilitate a conversation to get feedback and perspective
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:
- Efficient Updates: Maximum of one monthly email, keeping you informed without overwhelming your inbox.
- Gain Insights into Other Programs: Collaboration opportunities providing valuable insights into how other programs are operating; allowing you to learn from their experiences, strategies, and successes.
- Role-specific Training: Get notifications for engaging training sessions tailored to your role, ensuring you receive the training that matters most.
- Community Event Notifications: Stay informed about LACE Community events with topics of interest, providing networking and learning opportunities.
- Go to: https://qualitynet.cms.gov/listserv-signup
- Select Private Lists
- Scroll to Application Development Organization (ADO) Services
- Select the list that relates to your role at CCSQ:
Receive communications on how the LACE can help increase efficiency, responsiveness, and adaptability in the CCSQ community. | Receive communications about collaboration, value and delivery as a Partner Program Lead. |
Receive communications about how partnering Lean-Agile and Product Management greatly improve the efficiency and effectiveness in CCSQ. | Receive valuable communications about LACE services specific to Program Support. |
| |
Receive communications focusing on eliminating waste, managing processes, and delivering value. |
March 2024 — Defining Minimum Viable Product (MVP)
Tuesday, March 5th from 1:00pm - 2:00pm EST
CCSQ LACE Community Event: Defining Minimum Viable Product (MVP)
On Tuesday, March 5, we explored the transformative journey into the world of Minimum Viable Products (MVPs). Attendees gained invaluable insights into defining and delivering successful MVPs and unlocking the key to turning your visionary ideas into reality.
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
On Wednesday, December 6, the community event session explored the cutting-edge world of Artificial Intelligence (AI). This LACE Community Event was dedicated to unveiling the potential of AI tools and how they can revolutionize workflows, decision-making, and information management within the CCSQ community.
Attendees engaged with:
- AI tools showcase
- Recent updates on AI
- Practical applications in your daily responsibilities
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 explored the boundless possibilities of embracing agility to enhance our organizations' resilience and success. Together, we unlocked the potential of adaptive strategies, fostered a culture of continuous improvement, and built strong connections to thrive in an ever-changing business landscape.
Attendees:
- Discover what Business Agility is,
- Learn about the state of Business Agility in CCSQ,
- Gain insight from SAFe and
- Hear from speakers’ firsthand experiences.
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:
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:
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.
Effectiveness in the Remote Workplace
![](/download/attachments/533828951/Mindset%20Shift%20during%20a%20Pandemic.jpg?version=1&modificationDate=1707246980575&api=v2)
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
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.
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 Review | The developer has completed the story and needs it reviewed by a fellow engineer | In Progress |
In Peer Review | A fellow engineer is reviewing and discussing with the authoring engineer if/when changes need to be made | In 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 requirements | In 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 2 | Peer Review | Ready 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-Do | To-Do |
In-Progress: | A task/story has been started by an engineer | In Progress | In Progress |
Awaiting Review | A task/story is ready for review by another engineer | In In Progress | Progress |
In Review | A task/story is being reviewed internally | In Progress | In Progress |
Awaiting Awaiting Validation | The task/story is awaiting confirmation of completion | In Progress | In Progress |
Complete: | The task meets the release criteria defined in the team's definition of done | Done | Done |
Abandoned: | The team has made the decision that the task is no longer necessary. | Done | Done |
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:
- https://miro.com/blog/remote-team-building-activities-games/
- https://www.atlassian.com/blog/teamwork/virtual-team-building-activities-remote-teams
- https://www.lucidchart.com/blog/virtual-remote-building-games
- https://slackhq.com/remote-team-building-activities
- https://info.trello.com/embrace-remote-work-ultimate-guide
How to Use Zoom Meetings
How To: | Description: |
---|---|
Sign Up & Downloading | Zoom 101 Sign Up & Download Meeting Client |
Joining a Meeting | Joining 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 Screen | This video covers screen sharing and related Zoom collaboration tools. |
Remote Collaboration Software & Tools
Currently Approved for use in the CCSQ Virtual Workplace:
- Webex ( http://www.webex.com )
- Zoom ( www.zoom.us ) for virtual meetings
- Mural ( www.mural.co ) for collaborative work space
- A step-by-step video guide for Mural tool and PI Planning created by EQRS ( https://screenrec.com/share/d15rJFtSoT)
- Weekly Live Demo presentation (https://start.mural.co/resources)
- Slack (www.slack.com) for chat
- ScreenRec (www.screenrec.com) A free online screen recorder for making tutorials and video how-to's
AgileCards - Agile Cards empowers any agile team that needs to integrate their digital Jira Scrum or Kanban board with the agile task board on the wall. Move printed user stories during your daily scrum and use the app's synchronisation feature to match boards.
Botpress - Botpress allows users of your confluence space to interact with a question and answer bot
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
- https://www.planitpoker.com/ (free)
- https://scrumpoker.online/ (free)
- https://scrumpy.poker/ (free)
- https://firepoker.io (free)
Retrospective
- https://ideaboardz.com/ (free)
- https://retromat.org/en/ (free)
- https://funretro.io/ (free)
- https://www.goreflect.com/ (free for 100 days)
- https://www.teamretro.com/ (paid)
- https://metroretro.io/ (free)
- https://dotstorming.com (free) - Dot voting tool
Story mapping, white boarding, and other collaboration tools
- https://miro.com/templates/ (free)
- https://www.avion.io/ (free trial)
- https://trello.com/ (free)
- https://pickerwheel.com/ (free)
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.
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:
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. |
|
|
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. |
|
|
1:00 – 3:15 | Final Plan Review and Program Risks | Zoom Session with RTE presenting Mural page and Confluence page with Teams’ Final Objectives |
| |
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 |
- No labels