Horizontal Navigation Bar Page |
---|
|
Tabs Container |
---|
|
Tabs Page |
---|
| 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. 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 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 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 | 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 | 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 | 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 | 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) |
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 |
---|
| LACE Social Contracts and Team Agreements: Working Agreement- 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
- 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.
- 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
- 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
|
Tabs Page |
---|
| LACE Social Contracts and Team Agreements: Definition of ReadyWe 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- 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)
- 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
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. |
|
Tabs Page |
---|
| LACE Social Contracts and Team Agreements: Definition of DoneWe 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
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 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 standardsEnsure 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 requirementsAll 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
Names for objects, classes and functions are human readable The code contains lean but descriptive comments
Unit Tests coverage is XX% Code is peer reviewed Integration tests are included The code builds successfully into the integrated solution
Each Acceptance criteria has been met The work meets the goal of the user story
The work has been demonstrated to the Product Owner The Product Owner has changed the status of the work item to “Done”
|
Tabs Page |
---|
| 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.
Rapid setup and Jira import instructions
Capacity and load cards for each iteration
|
Tabs Page |
---|
title | PI Planning Supplies |
---|
| Download the Excel document here. |
Tabs Page |
---|
title | 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:
Widget Connector |
---|
url | https://www.youtube.com/watch?v=PWfCvSUBnHE&t=7s |
---|
|
|
Tabs Page |
---|
title | Psych 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 |
---|
|
Tabs Page |
---|
title | Psychological Safety |
---|
| • What was the primary cause of your withholding? • What was the primary consequence of your holding back? • 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. • 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? • 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 |
---|
| 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. - 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.
- 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.) |
Tabs Page |
---|
| 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 - 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
|
|
|
Tabs Page |
---|
|
Image Added - Efficient Updates: Maximumof 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:
Image Added | Image Added | 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. | Image Added
Receive communications about how partnering Lean-Agile and Product Management greatly improve the efficiency and effectiveness in CCSQ.
| Image Added | Image Added | Receive valuable communications about LACE services specific to Program Support. | Receive communications focusing on eliminating waste, managing processes, and delivering value.
|
|
|
|
Horizontal Navigation Bar Page |
---|
|
Tabs Container |
---|
| Tabs Page |
---|
|
CCSQ LACE Community Event: Defining Minimum Viable Product (MVP) Join us, on a On Tuesday, March 5, we explored the transformative journey into the world of Minimum Viable Products (MVPs) at our March Community Event. Attendees will gain gained invaluable insights into defining and delivering successful MVPs and unlocking the key to turning your visionary ideas into reality. Image Removed Session Resources: More information to come!
|
Tabs Page |
---|
| CCSQ LACE Community of Practice: Using Using AI To Increase Productivity Join us, for an enlightening session exploring On Wednesday, December 6, the community event session explored the cutting-edge world of Artificial Intelligence (AI). This LACE Community Event is 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 will engage engaged with: - AI tools showcase
- Recent updates on AI
- Practical applications in your daily responsibilities
|
Tabs Page |
---|
|
CCSQ LACE Community of Practice: Empowering Business Agility Agility
During this CCSQ Community of Practice event, the LACE will explore explored the boundless possibilities of embracing agility to enhance our organizations' resilience and success. Together, we unlock unlocked the potential of adaptive strategies, foster fostered a culture of continuous improvement, and build built 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.
|
Tabs Page |
---|
|
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.
Introduction - Zoom Poll and Welcome Participants
Keynote: Mindy Riley – Beyond SAFe: Program Transparency and Accountability Tacit Agreements + Discussions Persistent Agreements Break (10 Minutes) Completion Agreements + Discussions Commitments + Discussions The Funnel of Accountability Discussions: Improving Accountability |
Tabs Page |
---|
|
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.
- 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
|
Tabs Page |
---|
|
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. 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 |
---|
title | TOOLKITS & TEMPLATES |
---|
|
Tabs Container |
---|
|
Tabs Page |
---|
title | Effectiveness in the Remote Workplace |
---|
| 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 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. 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" 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. 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. 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. 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. 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 BoundariesMaintaining 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. 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 |
---|
title | Best Practices for Virtual Collaboration |
---|
|
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. - 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 |
---|
title | 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. 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 In order to support enterprise metrics, no statuses should be mapped to "In Progress" until development work begins Recommended Story States and DefinitionsNew: | 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 |
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 TeamsTo 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 |
|
Tabs Page |
---|
title | Communication & Remote Collaboration |
---|
|
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.
- 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.
- 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
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.
- Manage Your Work: Keep status and ownership of work items up to date. (see: See Work Item Management Best Practices in the Toolkits & Templates)
|
Tabs Page |
---|
title | 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. |
|
Tabs Page |
---|
title | Remote Collaboration Software & 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. Story mapping, white boarding, and other collaboration toolsSome 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 |
---|
|
Tabs Page |
---|
| 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 Team Breakout Virtual Boards (click to download Excel file) ART Remote Checklists (click to download Zip file) https://bit.ly/2UecirU
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
|
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 |
|
|
|
|
|
|
|