Team Charter and Norms: Working together
In my previous blog post, I wrote about setting up a Team Charter and Team Norms on a team. In this post, I elaborate on some of the rules of engagement that teams I have worked on have generally used.
Most software development teams that I have worked on have used some sort of Agile practices like the Scrum framework where cross-functional teams use iterative and incremental processes to improve their software delivery process. I have always used Agile in a way that works best for my team and the company’s culture at that time.
🧱 Team Structure
I have had to occasionally run Scrum meetings as an Engineering leader since I have been on teams without dedicated Scrum Facilitators or Product Owners. Each Scrum team usually includes an Engineering Manager, Scrum Facilitator or Project Manager, Product Manager and Developers. In the absence of dedicated Project Managers or if there is leadership interest on the team, I make the Scrum lead role rotational so that every person on the team gets the opportunity to be a Sprint Lead who operates as a Scrum Facilitator for a sprint.
📖 Rules of engagement
I have made assumptions in the past of how a team works every time I join a new team or start a new job because of my past experience or preconceived notions of how Agile teams should work. I have recognized some unwritten “How we do Agile” rules that I have written down here for future me. These rules could end up in the Team Charter (Refer my previous blog post “Documenting a Team Charter”) once the team meets to do Team Norm settings.
Sprint
Every sprint is 2 weeks long.
We start the sprint after Sprint Planning on Monday and end the sprint the next week on Friday.
We do Backlog Refinement with our Product Manager the week before the sprint to get an idea of what requirements and features are upcoming.
Backlog Refinement includes breaking down User Stories written by Product into engineering stories by engineers. After we agree on the Acceptance Criteria, we story point using a Planning Poker tool on Slack or the web and move this ticket to the top of the backlog based on priority.
At the beginning of the sprint, we have a Sprint Planning meeting where we do a quick Sprint Review of issues completed and not completed in the past sprint by looking at reports and burndown charts and sprint velocity.
Based on our sprint velocity, we pull in already groomed tickets from the backlog until we hit our team’s velocity.
If there is scope creep, then we de-prioritize work that hasn’t been picked up during the sprint and move it to the next sprint or top of the backlog.
We can sometimes groom tickets in the team Slack channel if it comes up after a Backlog Refinement meeting.
We trust each other to do the work assigned to them.
We ask for help in slack or at stand-up when we are stuck on an issue and cannot solve it in x amount of time.
Sprint Retrospectives
After we end the sprint, we have a Sprint Retrospective meeting to talk about how we can improve our team’s processes.
We assign a person to each action item that comes out of the Sprint Retrospective for accountability. The assignee is responsible for following up on their action item.
At the next Sprint Retrospective, we will review the action items first so we hold ourselves accountable for change.
Sprint Retrospectives are blameless and input is anonymous. We use tools such as EasyRetro or Retrium or Confluence or Google Docs.
The retro board is shared 2 days in advance by the Sprint Lead or Scrum Facilitator or Engineering Manager.
We have 4 columns for input in the Sprint Retrospective document - Kudos, What went well, What could go better, and Action items.
Story Points
We use the Fibonacci sequence of story pointing tickets. A ticket can be story pointed as 1, 2, 3, 5 or 8 based on what the team agrees upon as a group.
Story points do not equate to time required to do the work. They are estimates based on the complexity of the work.
No ticket can be more than 8 story points.
We break down tickets that have a complexity of more than 8 story points into smaller tickets.
We assume that every developer’s capacity on the team is 10 story points per week. The sprint velocity is 40 per sprint for a team of 4 developers, without any scope creep.
Each developer works on 8 story points of feature work and 2 story points of bugs and engineering maintenance work every sprint.
We account for team velocity changes in advance for when developers are out of office on vacation or illness.
Tickets and Pull Requests
A ticket can be a bug, user story, task, or epic. Each of these can have their own issue template.
Every ticket has a clear agreed upon Definition of Done in the Acceptance Criteria.
Issue and Pull Request templates are agreed upon in advance by the team.
Every Pull Request uses an auto-generated template with the following information
Issue or ticket number
Relevant screenshots
Testing steps and instructions
We have an agreed upon naming convention for branches.
We do all our feature work in feature branches and merge into main when the Pull Request for that feature has been approved.
Each Pull Request needs at least 2 LGTMs (Looks good to me) or 2 +1s.
If someone’s Pull Request breaks the main build, they are responsible for fixing the build.
When no Scrum Facilitator exists and a developer has taken on the Sprint Lead role, their individual capacity is going to be 8 story points instead of 10.
How we meet
Meeting invites are on the team calendar and are managed by the Sprint Lead or Scrum Facilitator or Engineering Manager. Every member of the team has editor access to the calendar.
We meet every Monday, Wednesday and Thursday for the Stand-up meeting for 15 minutes.
We add Stand-up updates on Slack every Tuesday and Friday when the Slack reminder goes off in the team channel.
We meet every other Monday for Sprint Planning for 30 minutes.
We meet every Wednesday for Backlog Refinement for 30 minutes.
We meet on Thursdays or Fridays for Sprint Review and Retrospective for 30 minutes.
We agree on core meeting hours across time zones.
We take time off once a quarter for at least a week.
We update Slack, email, calendars for longer out of office days at least 2 weeks in advance.
On-call and Triage
We set alerts on our monitoring tools (Datadog, Sentry).
We identify experts on the team for different scopes of work.
We rotate the engineers every week so that every engineer gets an understanding of our triage process.
We pair up senior and early career engineers.
We de-scope something on the sprint by collaborating with stakeholders if an incident takes a longer time to resolve.
We write up a blameless post-mortem once the incident is over and publish it internally.
We update our runbooks and alerts during and after every incident.
Here’s how we pair up our engineers:
Feedback
We criticize in private and praise in public.
If we have any disagreements with a fellow team member, we pull them aside in person or set up a video call to chat with them and resolve it among ourselves rather than bring it up in a public venue unless warranted.
We can also choose not to give feedback directly and involve our manager for mediation.
Interviews
We pair up senior and early-career engineers to train people new to interviewing.
We give our feedback within 24 hours of completing our interviews with the provided tools of feedback.
The norms above do not mention all the rules of engagement for a team but are a good starting point for anyone joining a team as a Developer, Team Lead, Product Manager or Engineering Manager.
✅ Takeaways
Being explicit about how we work together creates an environment for people to do their best work together.
The tools do not matter. What matters most is that teams communicate and collaborate with each other across the company so that everyone is aware of the tasks they are accountable for and deliver the software within the appropriate timelines.
Photo by Nick Fewings on Unsplash. Emojis from emojipedia.org
Comments
Post a Comment