If your agile team events are meetings - you're doing it wrong!

Hello agile teammates!  Can I get real with you for a minute?  I want to share something that really gets my dander up... 

I don't know about you, but when I hear folks refer to our agile team events as "meetings" I get a special kind of cranky!  Let me explain...

 

As you all are very aware of by now, agile teams are built around a set of shared values and principles we call "the agile mindset."  The first shared value of that mindset is:

Individuals and interactions over process and tools

Now - tools and processes are valuable... they really help a team stay focused on their shared objectives (which of course is to deliver values for our customers while we achieve business outcomes!)  This may be an unpopular opinion, but I'll make the argument anyway - Agile team events are not a process, nor are they a step in a process.  They are not a box to be checked or a form to be stamped.  They are an opportunity for a cross-functional team to have a conversation and to come to a shared understanding
about -

• What they are doing,
• Why they are doing it, 
• How they are planning to get it done.

I know , I know... I can hear it already, "Coach Dan, I don't know what the problem is.. that's what we're doing.  We DO have those events!  We have the agendas and meeting notes to prove it!"  Consider this.... if your events are feeling like meetings (or your team feels that way...) you may be doing it wrong! 

What are these Scrum team events anyway?

Let's take a look at the Scrum team events, their purpose and what makes them good (or bad.)

Scrum Team Event	Official ScrumAlliance  definition...	Intended outcomes of the event...	This feels like a meeting...	This is the team being agile
Daily Standup (or Huddle)	The development team meets for 15 minutes (or less) every day of the sprint to inspect progress toward the sprint goal. They describe for each other how their own work is going, ask for help when needed, and consider whether they are still on track to meet the sprint goal. This is not a status meeting but is instead an opportunity for the development team to inspect and adapt the product and process on a daily basis.	Refinement of Sprint plan to enhance probability of meeting sprint commitment Impediments do not hinder the team’s progress More successful sprint/feature execution this sprint and over time	"Here is my daily status report" "Here are all of the meetings I went to yesterday. Here's the ones I'm going to today." "Are you done yet?" Hounding team members on if things are done. Sending out daily agendas or minutes.	Answering the three Standup Questions... ~What I stories/tasks I completed yesterday ~What stories/tasks I will complete today ~What are impediments or blockers that are in my way Asking for / offering to help a team mate who may be falling behind. Deciding to pull an additional story/task into the sprint because the team has extra, unexpected capacity. Celebrating small wins and lessons as they happen.
Backlog Refining *Note - not an official scrum event, but most teams use it so I included it anyway.	the product owner and some, or all, of the rest of the team review items on the backlog to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery.	The work brought into the sprint is understood to increase probability of success Team is clear on value of the story Team is clear on the success/acceptance criteria Team has reached consensus on the complexity of the story (relative sizing) Understand the problem or opportunity they are trying to solve/take advantage of	"I don't need to know what everyone else is doing." Uploading pre-made templates of stories or tasks without discussion by the team members responsible for completing them. Only one or two people offering ideas, observations or perspectives.	Discussion stories and tasks so that the team understands the what and why of what's being done. Team discusses complexity and dependencies and is aligned on the relative sizing (not hours or due date) of the story or task. The whole team understands what the definition of done is for the task or story.
Sprint Planning	During sprint planning, the entire Scrum team collaborates and discusses the desired high-priority work for the sprint and defines the sprint goal. The Scrum Master’s role is primarily to facilitate the meeting. The Product Owner describes the objective of the sprint and also answers questions from the development team about execution and acceptance criteria/criteria of satisfaction.  The development team has the final say in how much of the high-priority work it can accomplish during the sprint.	Team understanding of the sprint goals Team understanding what work they will be doing to meet the sprint goal Balance between probability of successfully meeting the sprint commitment and willingness to stretch and improve	"We have to have all of these tasks or stories done because - due date." Stories or tasks being "assigned" by a PO or Scrum Master. Little or no agreement that the sprint commitment is reasonable and achievable. Last minute stories and tasks added because "we forgot."	Team has an honest discussion about their capacity and only takes stories and tasks that they are sure can be completed within the sprint. The highest priority stories and tasks from the backlog are included in the sprint. Stories and tasks that are committed have been refined and "picked" by team members and not assigned by the SM or PO.
Sprint Review (or Demo)	print reviews focus on the product being developed, specifically on the potentially shippable product increment created during the sprint. During a sprint review, the Scrum team invites stakeholders to discuss what was completed during the sprint. They adapt the product backlog as needed based on this feedback. The Product Owner has the option to release any of the completed functionality.  Though a demo might be part of this meeting, the primary purpose of the sprint review is the inspect and adapt capability provided by the discussion.	Stakeholder partnership and alignment Understanding the state of the planned release Agreement on changes to scope or timeline of the planned release Agreement on next priorities	"We don't have anything to show so let's just cancel." ' "The user / sponsor won't care that we finished this part." The PO or Scrum Master does all the talking. No interaction / feedback / questions from the sponsors or users. Everything presented "in a deck."	Delivery team members showing off what's been completed within the sprint (even if it's a field being populated in a database behind the scene.) Imperfect or draft materials are shared to get directional feedback from users and stakeholders. New ideas for future improvements added to the backlog for consideration.
Sprint Retrospective	Sprint retrospectives focus on the process. During a sprint retrospective, the Scrum team discusses what went right and areas for improvement in the sprint. They make tangible plans for how to improve their own process, tools and relationships.	Continuous Improvement	"Everything was awesome." "(Insert other department or team) took too long to get their part done." "We can't fix the process."	The team has an honest conversation about how they are working together, as a team. Potential improvements are identified and agreed to be tested in upcoming sprints. Discussion on what went well, as well as what didn't. Team identifies and shares things they can't control, but focuses on things they can change themselves.

Team events are for the team (shocking, I know!)  They allow team members to exercise our shared agile values and principles, and to apply them to the work that they are doing together.  They are there to help foster a sense of shared accountability, not for just "doing their job", but for achieving the teams shared objectives.  They are there to help the team focus on the what the team has decided is most important and valuable for our customers.  If they start to feel like a waste of time, or that they aren't valuable - then there is an opportunity to improve the way you and your team are conducting those events.

Feeling like your events are meetings?  Fix it, don't quit it!

If you feel like your agile team is going through the motions, instead of using the events to have conversations - then it's up to you and your team to fix it.  Nothing is worse than wasting your time when
we could be creating value for our customers.  If the events aren't adding value, if they aren't helping your team to be effective, efficient and engaged every day, then it's time to have a conversation.  Team events are there to enable you to align on and then hold each other (and yourself) accountable for achieving the teams objectives.  If you're not meeting the "outcomes" of your team agile events, what's stopping you from having that discussion with the team?

Managers... are you hearing from team members that the events are a waste of time or not useful?  Time to get your "agile manager" hat on!  Some questions you can ask your team member...

• "What would a productive (insert event name here) feel like to you?"
• "How did you address this concern in the team's last retrospective?"
• "What are you doing to make this event more valuable for everyone?"
• "How can you show up confidently so the team feels encouraged and empowered as well?"

Agile Team Owners... getting feedback that there are too many meetings?  The team doesn't have time to get things done?  Some questions to ask your team...

• "What are some things that we can try as a team to make these events more valuable?"
• "How can I help the team feel safe and comfortable so they make these events their own?"
• "How can I help the team feel empowered to work differently together?"

Scrum Masters... seeing a lack of attendance, limited participation or engagement?  Getting feedback that the team doesn't see the value in "all these agile meetings?"   Some questions to ask yourself...

• "Do we have team culture that fosters honest feedback about what's working and what's not?"
•  "What might be causing some folks to "just show up" and not contribute to the conversation?"
• "Is the team managing their capacity and throughput in a way that's maximizing what they can get done for our customers?"
• "How can we ensure that our team members feel empowered to continually improve how effective, efficient and engaged we are as an end-to-end team?"

Questions like these are great ways to begin the conversation and to turn "I've got a problem" into "I have some things to think about to help solve my problem."

Final thoughts...

No one ever ends their week wishing they had more meetings!  Agile team events are in place to maximize transparency, alignment and accountability so the team can achieve their shared objectives.  If they are being viewed as "meetings", and not useful... then it's time for a conversation.  It's every single team member's responsibility to make these events work for them and the team.  Experiment and find ways to improve the way you're working together!

Go out and BE agile today!