The "Soft" Meetings, why we have them, and why they fail.
The most common concerns about agile meetings I hear are usually around the “soft” meetings, the scrums and the retrospectives. Specifically the questions often revolve around the fact that teams feel they are of nebulous value at times, and want to reduce them, or throw them out. This is especially true in teams new to agile culture.
Have you ever gone to a scrum and heard someone repeat the answers to the standard scrum questions as if they are an extra in a zombie movie? (Fade to black, fade in on a scrum circle: One person speaks in a monotone voice, his body almost twitching… “Yesterday I went to meetings and iteration planning. Today I am working on US666, and I am not blocked. I also need brains…”)
If you look around the circle and you see a group of people with glazed-over eyes, almost lifeless in their engagement, the meeting is either not working or they have been turned into scrum process zombies. Seriously though, if the team is looking at smart phones, shuffling or talking, falling asleep, and/or they just have hostile looks on their faces they may think this is a waste of their time. In an instance like this, I would agree with them. The reality is that in our soft meetings we get “stuck” on the procedure and lose sight of the intent. Let’s talk a little bit about why we scrum.
We must step back and remember our agile values first:
Communication, Simplicity, Courage, Respect, and Trust.
These values drive all our actions, because these values are the bedrock of how we determine how to act. With an agile system we don’t have all our actions spelled out for us in a process manual, so instead we have a system of values and principles that guide what ethical and effective actions look like when not defined.
Okay, so why so many talky meetings? In agile we think of communication as inversely proportional to waste. The less communication, the greater the waste injected. The greater the communication, the less the waste generated.
Communication, be it written or verbal, has the purpose of creating a shared pool of knowledge in the team. This shared pool of knowledge is a group understanding of the goals of the project the team is working on. It includes detail of each feature and function to be built. It also includes a full understanding of why we are building and what the value is.
The shared pool of knowledge exists in all software development. In predictive models this shared pool is built with documentation that quickly becomes stale and outdated if not constantly updated. In agile or adaptive models this pool is created with minimal documentation (User Stories, Demos, UI/UX Diagrams) and maximum communication. This pool of knowledge is built in iteration and release planning, but it is kept fresh in scrums. It is therefore as nimble at adapting to change, and remaining current to our objectives and work goals.
ProKarma's Approach to Agile Methodology
The Scrum Meeting
The scrum meeting is often described as a 15 minute meeting to air issues to the team and to be able to ask for and offer assistance from/to other team members. The meeting is bound by three questions. The most common form of scrum asks us to answer three questions:
- What did I do yesterday?
- What am I going to do today?
- Any issues?
Unfortunately when we get focused on this “process” we often lose sight of the real value of scrums. You see, these three questions are merely meant to prime the pump of communication, collaboration, and service between team members. The real intent of scrums is to maintain the shared pool of knowledge, and maintain it day to day to avoid waste, confusion, and team isolation.
Scrums also provide a day to day opportunity to team build, to understand each other’s challenges, and to support and praise one another. Even more importantly scrums build a feeling of community, trust, and yes even friendship across the team. In reality we need to change our focus in scrums from the questions, to our intent. The simplest way to approach this is to have all the team-focus on one ideal: that of serving each other as a team.
When we walk into a scrum one question should be on our minds: “What can I say at this scrum that will serve the members of my team?” If you need other ideas of what this service means, think of these questions: What do they (the team) need to know? What do I need to know? What help can I offer or do I need? Is there anything I am worried about that I want to ask about? This is a strong focus on service to your team, not a self focus.
Time Bound 15 minute Scrums, and 16th minute items…
Scrums are usually time bound to 15 minutes. Many times I have heard coaches or trainers insist that anything over that 15 minutes is wrong, and moving into waste. I strongly disagree with that take on the 15 minute scrum, and let me elucidate why.
Rigidly focusing on binding scrums with questions, protocol, or time limits can often kill their value. Fifteen minutes is a good guideline for a quick sharing discussion. The questions indicate the kinds of information that MAY be valuable, but they should not limit what is discussed or needed. I have seen 15 minute scrums that are worthless, and 30 minute scrums that are invaluable. It all comes down to how much we as team members show up, be present, and really try to serve other team members with the best we can offer. This aligns us with the values and builds an environment rich with trust.
To try to keep focus I divide my scrums into two sections. The first part is the quicker traditional update of work, and issues. It is focused, and seeks to align the work involved. However, very often to maintain the shared pool of knowledge a deeper discussion is needed as I have mentioned through this paper. After a team has gotten through a focused update I call out: “Are their any 16th minute items for discussion?”
16th minute items are the broader discussion, airing of concerns or issues, and general discussion that keeps that shared pool of knowledge fresh. As the scrum master you should always seek to keep the 16th minute items focused. If a long discussion is needed about architecture, or data, or anything else use the 16th minute time to surface it, and quickly assign an action plan to address it outside of scrum. This can be as simple as saying. “Hey Bob, you and chuck talk about that offline and let the group know how it resolves tomorrow would you?”
I have found that the 16th minute items often provide more value to the team then the traditional portion of the scrum, though both are important to maintaining the shared pool of knowledge, and team focus.
So in summary, a scrum is a meeting where we all seek to keep the shared pool of knowledge as updated and accurate as possible. We do this by focusing on the intent to be a team player and really trying to offer anything we can to keep the team informed and running smoothly.
In all of this we must consider one last thing. When dealing with others on a humanistic level, we must be careful not to exceed their capacity or comfort zone of “personal” space. The SM and team members must always be on the watch to deal with the human side of the equation, without overtaxing the teams ability to work in a humanistic space.
Corporations have been training people in mechanistic process thinking for a long time. Most people have a degree of this training in them and are comfortable with the lack of soft skill usage in development process. Therefore, moving a team to a stronger humanistic culture takes time, a slow building of trust, and a reprogramming of ideals on how we do business.
As an agile coach, scrum master, or team member, always ask yourself if the person or team is ready for the lesson if you need to challenge them to grow. It is okay to push boundaries, just not to the breaking point. Lots of listening and feedback will help you set the right pace.
So in all soft meetings in agile, we must first focus on the intent of the meeting, and then look at how that works toward a solid team that supports both agile values and operations. We need to keep ourselves present and focused in these meetings to provide good work. We need to not exceed the capacity of team members to be challenged and to challenge each other. If we do these things, then we can build truly high functioning teams with an atmosphere that anyone would like to work in. We focus on the true intent of agile, which is strong relationships that lead to inspired engaged people. There is no process that inspires. People inspire other people. Communication and respect come from a constant of hard work, and showing up and owning our mistakes and victories to each other. Don’t turn into process zombies. Focus on each other, and these meetings may become your favorite part of your agile ceremonies.
The Fundamentals of Agile Leadership