Joe Harrington

The best way to encourage participation in your daily scrum is to make the daily scrum a ceremony that is both valuable and fun for the team. Maintain your timebox for the scrum and don't let it extend beyond it without getting the team to agree unanimously on extending it. I've rotated the facilitator role between team members, held themed scrums, incorporated demos into the end of the scrum, and I've kept devs guessing on who will speak next, and varied how I facilitate it (rather than going from dev to dev, going by user story or bug).

At Foresight Sports, I facilitated a Team Agreements meeting to establish expectations for the team, including on meeting attendance. The team agreed that all team members should attend the scrum, found a time that worked for everyone (despite crossing 4 time zones), and accounted for absences. We documented what a team member should do if they miss a scrum, if they know ahead of time that they are going to miss a scrum, and how to handle planned absences. It's useful to document protocols for when absences happen, but it's far more effective to get to the reason why the absences are happening. It's important to convince the team that they have valuable information about their work that they should share with others to ensure collaboration.

Understanding the reason why the team member is late to the Daily Scrum is crucial to addressing the issue. If they are late because they have conflicts, then look into possibly rescheduling the scrum to a time that works for all team members. If they aren't showing up because they're losing track of time, multitasking, etc., it's worth reminding them of the value of the scrum, which is maintaining alignment on the work, demonstrating respect for others, and collaborating with the team to accomplish the sprint goal. I would recommend facilitating a Team Agreements meeting to establish some standards for attendance, and I would come to an agreement with the team member on how to improve their attendance using metrics to measure progress.

Agile may be a thesaurus entry for "flexible," but it doesn't necessarily translate in every use of the word. Business agility is different than accepting every change to project scope that stakeholders want. In fact, product owners, product managers must have the autonomy and feel empowered to say "no." Clients should be able to control two of these three variables: delivery date, budget, and scope of work. If they want a project by a certain date and to cost $X, then you must determine the scope of the work based on your team's capacity. If it's a quality metric of work and $, then you will need to advise on when you can deliver. If it's scope and time, then you must advise on what budgetary adjustments are required to resource it.

In Agile, we value individual and interactions over processes and tools and working software over comprehensive documentation. That is not to say we do not value the things on the right, only that we place more value on those on the left. Thus, when changes inevitably occur, it's more important for your team to be focused on the outcomes and the intent of the changes than it is the particularities of the documentation or requirements. It's paramount to understand the change, why it's happening, and how it aligns with the strategic themes guiding the organization. That's how you can ensure the changes are effective, and to ensure your team doesn't get lost in the weeds.

Transparency is the name of the game when it comes to building trust. It's critically important to communicate effectively with clients to ensure alignment on goals and transparency on the process. Clients need to understand that they are part and parcel to the development process, and their active participation and feedback is what drives quality and innovation. In communication, don't steer away from highlighting areas where client input is needed, and adapt your communication to their level of technical knowledge. Never assume their knowledge levels, and do not condescend.