1. Speak the business language to avoid misalignment

Communication is a crucial aspect of scrum. Having a proper feedback flow with clients and mutual understanding between them and the team is fundamental to get the desired result. But, can stakeholders be considered part of the team?

For David Alzate, the answer is no. In his experience, he considers that one person should be directly in charge of bringing together all the details of the product, to avoid passing that responsibility to the scrum master.

“When you take that responsibility to the scrum master, in the end, he is becoming the product owner as well, because he is the one with all the answers,” Alzate said. “So, we try to have a product owner, and he is the one in charge of getting the information. We don’t let the team do it, because they are busy, and we try to let them focus on the code,” he added.

Speaking the same business language can be a challenge in teams that include people from a wide range of areas. Having that in mind, Dennis Humes asked the other participants about their experiences in building cross-functional teams.

“When I worked in a manufacturing company, we were about to make changes to our warehouse management system. The decision was to have a cross-functional team, people from the warehouse, people from customer service, etc.” said Humes, before asking who should be included.

For Jun Chic Caslen and Karen Vargas, it all depends on the size and type of the project. However, Jun Chic emphasizes the role of the product owner in facilitating communication between the “businesspeople” and the team.

“You can have a product owner that has all the business knowledge, and in that case, you would probably only have one, and if he has questions, he would reach out to other stakeholders, and get the information -probably as a facilitator-, and it to the cross-functional teams, so that they can work together with the product owner, and flush out all of the requirements and the questions that team has,” she said.

2. Keep your estimating process stable

Most of the scrum masters that participated in the session use the scrum poker or planning poker technique for estimating. Scrum poker is a consensus-based, gamified technique used to estimate effort or relative size of development goals in software development.

All of them agreed that on the first three sprints, usually, the estimations are not good, because it is the part of the process in which the team is getting used to the project and to each other. After these first sprints, estimations should stabilize.

“Usually after the fourth sprint, what we commit to, we deliver,” Alzate said.

“What you want first is to find stability,” Jun Chic said. “You want to maintain your team on the same number, at least for three sprints or measures, and then, once you have the stability, then you look for improvement. Because that’s when you know that you have found synergy among your team, they know each other, they know how fast they are moving, they know how to estimate, and they are on the same page,” she added.

An important aspect, however, as Dennis Humes mentioned, is to avoid comparing teams on the velocity and the rhythm they follow, because each team works differently.

3. One-week versus two-week sprints

The typical sprint flow is two weeks. However, among the session participants sprint periods range from one week to three or four weeks. What are the advantages and disadvantages of each type of cycle?

On one hand, Jun Chic Caslen, from iTexico, works in one-week sprints. She thinks this model is useful to keep clients happy.

“You are delivering on a weekly basis something functional, so the clients are happy. That gives them, more than anything, visibility of what you’re doing, what you’re working on, faster feedback, on-time feedback, and being more open and prepared for changes when needed,” she said.

On the other hand, she mentioned stress as a disadvantage. Developers may burn out. Working at this rhythm requires the company and the clients to employ several techniques to keep the team motivated.

For David Alzate, Martin Rotaveria and Dennis Humes, sprints run usually for two weeks, and that has worked well.

Karen Vargas, at Prodigious, is currently working with sprints that range from three to four weeks. In her case, she explains that this is due to the size and complexity of projects she is working on, which often involve as many as 200 people.

4. Fast-paced development can undermine retrospective meetings

Retrospective meetings, planning and reviews are core aspects of what makes scrum an agile methodology. But, from the experiences of the session participants, Huber Smits (guest moderator) observed that an overtly fast-paced delivery mindset can cut out those prescribed moments of reflection.

Even in Karen’s team, which has longer sprints, this happens. “Even when we don’t have one-week sprints, we have that kind of pressure where the team wouldn’t feel comfortable having meetings or having a full retrospective for two hours, as we should, or even the grooming, because they have so much to do,” she said.

For David, this is one of the main factors that made him switch from one-week to two-week sprints, since in the other model, team members don’t want to have meetings, because they have bigger burdens.

“Retrospective happens when we have our status meeting on Mondays,” said Jun about how they have shortened their process. “We have a very quick retrospective: what went well, what we could improve, just with the project leads. It’s like 25 minutes,” she added.

5. Waterfall is dead – nobody wants it back

Despite all the challenges, the stress, and the fast-paced environment that can come from agile software development, none of the scrum masters would abandon the methodology. Going back to waterfall is just not an option.

“I had just one experience of a successful waterfall project in my life,” Rotaveria said. “There was a lot of change all the time, a lot of frustration, a lot of stretching the deadlines because there were more changes, and we needed to rework some stuff,” he added.

For Rotaveria, there is a reason why scrum and agile methodologies came about, and he thinks it is precisely to mitigate the wait for feedback. “It’s better for the developers because they speak with the people on a weekly or biweekly basis,” he said.

“You don’t want your team sitting in a room for two months, and then you don’t hear from them for those two months; and finally the client says ‘no guys, that’s not what I want, you have to go back for another two months and come back,’” Humes said.

For Karen Vargas, waterfall is frustrating because you spend months designing, and you don’t get that certainty that you are working towards something that aligns with what has been mentally imagined.

“Being able to have the client see something every certain time is good for the client. But it also is something that helps us with the team. I keep telling my guys that whenever we are working on a project, I feel like I’m going to give birth to a child,” Vargas said.

“You’re always within those nine months waiting and waiting, and in the end, the very happy part of that is when you actually have the child in your hands. Being able to work with scrum gives the guys in the team that possibility of having the product of seeing their effort built into something that they can actually present to someone else,” she added.