Growing up in a single-parent family with three brothers, we did not have a lot of money. What money we did have my mother spent on our education, food, and clothing. From time to time, we went without some other basic necessities. Once when I was eleven years old, our phone was disconnected due to lack of payment. This was before cell phones, texting, the Internet, or cable television; the good old analog telephone was my conduit to the world, and I needed that phone to stay dialed in (pun intended) to the fifth-grade scene.

After a few weeks, I asked my mom when the phone would be back on. She didn’t have the funds to pay the full bill, so she said she didn’t know. I said something to the effect that surely something could be worked out. I asked her to drive me to the telephone company, and she reluctantly did so. By myself, I walked into the white brick building and took the steps to the second floor. I met with the clerk and explained our obvious need to have a telephone. I then negotiated a deal of twenty-five dollars per month to get the phone back on.

What Does This Story Have to Do with Agile?

About four years ago, CA Technologies began its agile journey. I led the effort to integrate our global team of technical writers, about two hundred strong at the time, in agile, specifically Scrum. Since then, some teams have also embraced kanban and the Scaled Agile Framework (SAFe). As I led the education effort, we held workshops and office hours and completed corporate web-based training. During all these sessions, my mantra for success was Speak up.

I am naturally outgoing, so I appreciate many of the social aspects of agile, such as regular human interaction, a customer-centric focus, and constant collaboration. I am also not afraid to ask questions: Why would the customer want to use this feature? How would a customer use this feature? Why are we going with option A instead of option B?

These are all valid questions I asked during planning, standups, and retrospectives. Sometimes, the team had good answers. Sometimes, they did not. Either way, I know I propelled the team in a positive, more productive, customer-focused direction.

For example, I worked on a team that was building a new product. We knew we had an innovative product, but it was challenging and time-consuming to install, so I spoke up: Why are we focusing on building new features when clients struggle to install the product? If they cannot install it, does it matter if the feature set is rich and robust? We met with field support and clients who confirmed that, yes, they liked the feature set, but installation remained excessively onerous. Several team members then submitted ideas to improve the installation process. I also proposed stories to improve the process and associated documentation.

In the end, the team agreed. We simplified the installation and documentation, and in the end, the field support team and clients were pleased with the improved installation process.

My takeaway from this experience? You can master rituals and ceremonies. You can master the story-writing format and grow skills as an estimator using story points. You can meticulously manage your stories to maintain a healthy burndown. You can even learn all the theoretical agile principles and best practices—but you still may not be agile. To be truly agile, you must also speak up.

How, When, and Why Should You Speak Up?

All forms of agile are a self-managed methodology. Whether you are an introvert, new to the team, or new to the technology, you are part of a dynamic team that uses a methodology based on open dialogue.

Awhile back, I was coaching a writer who was new to the team and the technology. He admitted to me that he was hesitant to ask questions in team meetings. I reassured him that the team wants feedback and input, and as a new team member, his perspective could be very beneficial. In his next planning meeting, he asked for clarity regarding the business value of a story. It turns out the others were confused as well. A twenty-minute conversation ensued where the team refined what they were doing and why. The writer beamed as he shared this outcome.

You can do it, too.

During release planning, confirm with the release team that the proposed feature set is what the customers really want, instead of what we think they want.

During sprint planning, confirm that you and the team understand the goal of a story—the business value and technical details. Why are we building xyz, and for whom? Identify how someone might use a feature so the team can build the code and documentation appropriately. If a story is sketchy and you ask these questions, other team members will likely chime in that they, too, need some clarity. Once you get more details, the team can meet its sprint commitments with deliverables the client wants and with code and documentation with strong usability.

During the sprint, inform the team when you have bandwidth and can help with a task, even if the task means stepping outside your comfort zone. Volunteering like this perpetuates a team-first dynamic and ensures that the team meets its sprint commitments.

And at the end of sprint, raise issues in the retrospective so the team can truly continuously improve—be bold, be factual, and be respectful. Engage customers in demos so that you can confirm they see value in what the team has built and that you can work together on how you can iterate and make the product and process even better. This way, you promote team growth and efficiency as well as open collaboration with clients.

Agile is a seemingly simple methodology with many nuances, best practices, guidelines, and certifications. However, to truly succeed in agile, we must communicate effectively and assertively. You can do so in person, in a meeting, in an instant message—or even via a (working) telephone. You do so by speaking up!