In this series, we will look at how to use the Open Practice Library to form a team, define and align the team’s goals, and deliver on those goals.
Simple open practices to facilitate success for a new team
In this post, we’ll discuss the process of creating a new team and lay out a set of Open Practices for a firm foundation for success. All of the practices described here can also be found in the Open Practice Library.
The Team is Assigned
We’ve heard this story before. The company wants to be more “Agile,” so they’ve selected a group of people to be the new “Scrum” team. They’ve moved their desks to a different area of the office, and have the responsibility of producing a new product or feature. That product or feature may already be defined. Still, most likely, it’s a vague idea handed down by some project manager who heard it from five levels of management, who all were trying to spin an executive’s vision. A manager is assigned that hasn’t worked with any team members previously... Now what?
Team Forming
Social Contracts
Before our personnel can get to work on the “what,” they need to learn how to be a team. First, we need to understand what a team is: a group of people dedicated to working together to achieve common goals. Teams need to define how they will work together and what their desired team culture will be. An open practice we suggest using is the Social Contract.
Social Contracts are a great tool for a team to use to define their culture. Is the team strict on the process? Is light humor part of how the team communicates? The Social Contract answered these questions. Some common items you may see in a Social Contract include:
- Assume positive intent in communication
- Assume expertise exists
- Step outside of the team’s work area when taking calls
- Close or lock laptop screens when meeting with the team
- Team-building activity the second Friday evening of each month
- No team meetings between 10:00 and 14:00
Team members can formalize their Social Contract by signing it and displaying it publicly on a wall for everyone to see. This sets expectations for the team members as well as for colleagues from other teams to ensure mutual understanding and respect.
Definition of Ready
Once a team’s Social Contract is created and agreed upon, it’s time for the team to decide how they will determine that a work item is “Ready to Work.” This is where the Definition of Ready comes into play. Essentially, the Definition of Ready contains the criteria that the team agrees any work item or “Story” must satisfy before being included in a Sprint and picked up by a team member to complete.
Some common items one might see in a Definition of Ready include:
- Estimable
- Able to be done in a single sprint
- Testable
- Valuable
- No external dependencies
- Contains a Definition of Done
Adhering to a Definition of Ready helps to mitigate “scope creep” and also ensures that every team member knows what to expect when taking on a new work item or story.
Definition of Done
The Definition of Done applies to every work item or story a team generates. It ensures there is no question by any team member of when the work is “complete” and, like the Definition of Ready, assists in reducing “scope creep” and setting expectations.
Some common items one might include in a Definition of Done are:
- Tested
- Automated
- Documented
- “Green” in security scanning tool
- Reviewed and approved by two team members
- Contains a demo video
Priority Sliders
Now that the team knows how to work together, how to determine the readiness of work items, and how to decide when a work item is complete, it’s time to solidify the team’s priorities. For this, we use Priority Sliders. This practice makes it easy for the team to visualize decision-making criteria; it assists in answering the question of “How do we decide which item to work on first?”
Some common items found on priority sliders include:
- Security
- CI/CD
- Functionally Complete
- UI
- Training
- Test Completeness
Priorities may change based on business needs. While it’s valuable for a team to understand how they prioritize topic areas as a team, stakeholders participation in these activities ensures that the team and their business stakeholders are aligned on expectations.
Conclusion
Once a team has a Social Contract, Definition of Ready, Definition of Done, and are aligned on how to prioritize their work, they have a firm foundation with which to build upon. In the team’s infancy, usually the first four sprints, it is important that each team member strictly adheres to these core practices so that they become a part of the normal workflow.
In the next article, we’ll look at practices the newly formed team can use to align on goals and translate those to work items.
Open Practice Library series on the Red Hat Blog
Learn more about our community-driven collection of exercises for making incremental progress along the product delivery cycle from the full Open Practice Library series:
저자 소개
Brian Tomlinson is a Senior Architect with many years of experience contributing to Linux and FLOSS communities as a user, administrator, and contributor. His work at Red Hat includes delivery of Red Hat Open Transformation, Kubernetes Operators, Container Application Development, and Hybrid Cloud Infrastructure for Red Hat Services customers.
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.