Get certified - Transform your world of work today

Close

Applying Common Sense to the Agile Framework

30 July 2015


As a developer, ScrumMaster, and product owner, I have written articles and had talks, sharing my knowledge with the community and evangelizing the Agile method to anyone who wanted to be part of the Agile movement.

After becoming a Certified Scrum Professional®, I wanted to share the steps that I followed during these years, which have helped me to create Agile teams, resolve conflicts and problems, enhance communication, and improve the working environment. I have observed that the people around me who participate in Agile implement such guidelines in varying measures, and I'm always pleased when they have experienced improvement.

The following guidelines have helped me create efficient Agile teams:

Conduct meetings around the task board. You can use digital tools, but always try to have a board area to display your work and hold meetings. Try to synchronize the task board with the tool that you're using.

Learn to conduct Daily Scrums. The Daily Scrum is a powerful weapon in the Agile world. Daily Scrums are helpful in resolving problems and assisting with reaching the common goal, which is simply to complete the tasks successfully in the sprint or to deliver the highest possible value. But the daily meeting is not a progress report by either the team or by the ScrumMaster, and even less a report from management or the product owner. If our Daily Scrum becomes a "status report," it's better to quit the meeting until it's the right climate to recover and foster cooperation, transparency, and confidence in the team.

Change the questions daily. There are three questions that are usually asked during the Daily Scrum:
  1. What did you do?
  2. What are you going to do?
  3. What problems have you found?
For some teams these questions do not provide any insight. Rather, the answers end up being a status report. The team loses creativity or the desire to perform the Daily Scrum. They think, "Every day is the same story." When this happens, we have to change the strategy.

Three new questions to ask:
  1. What have you completed?
  2. What are you going to complete?
  3. Are you sure you've ended up with no problems?
Change the questions, and you change the vision. The team member no longer focuses on what he or she has done or what he or she has worked on since the last daily. If the members are not committing to completing tasks or stories, a major new commitment is acquired beyond just work.

Share the burn-down chart in the Daily Scrum to view the team's progress.

Do not talk if it's not your turn. Among Agile's values are communication and focus, but there is one value above all: respect for people. We must build teams with courtesy and respect. Therefore, if it's not your turn to speak, do not interrupt. If you are brief and effective, your conversation adds value.

Use the parking lot. Try to be concise. One of the reasons that a team may not want to do the Daily Scrum is because too much time is spent talking about things unrelated to the meeting agenda. Park these issues for later. They may be unrelated to the sprint or out of alignment with the intent of the daily. Take them and post them to a whiteboard after finishing the Daily Scrum. In the meeting, however, direct your attention to relevant issues and to the common vision of the team. You can discuss the other topics, which may be as important as the Daily Scrum, but now is not the time to address them.

Stand up for the meetings. A daily meeting or a retrospective is often much more effective standing than sitting. Otherwise, people can lose their concentration, relax too much, and try to entertain themselves. If you hold the meetings standing up, people are more agile, quicker to talk and resolve problems and issues, and eager to satisfy the objective for that meeting.

Change to a "meeting hospital." If the daily becomes a dangerous meeting, with problems, conflicts, or tention within the team, it is better to change to a "meeting hospital" to address these issues. There you can try to identify the problems and solve them with transparency, honesty, and communication.

Use a token to assign a speaker. To facilitate the Daily Scrum or gatherings where shifts in word or speech applications are not respected, it is useful to use a token (an object selected by the team). The token gives the user of the object the power to speak at that moment.

Respect the allotted time. Go to meetings with a well-defined script that you've planned in advance. This will help the members to respect the time, terms, and topics, thus giving value and the authority to postpone further discussion. We must be Agile, maintain focus, and not overwhelm or tire the "audience" -- ourselves. Try to provide 24-hour advance notification for any future meeting.

Uphold the level of commitment. Keep the team committed by displaying their work, such as velocity, continuous integration status, or automated tests. Avoid boredom and lack of motivation. Visualize the commitment with information radiators posted in a highly visible area.

Learn to say "thank you." Thank any team member who speaks well of you, acknowledges your work, or notices when you criticize constructively. Gratitude makes the team stronger.

Do not obstruct the iterations. Try not to hinder the iterations, especially during the first third and last third of the time frame. Facilitate the iteration in the middle phase by setting up the appropriate prioritization meetings, grooming, etc.

Make the product owner work. Not only do the team and ScrumMaster have to work during the sprint but the product owner does too. The product owner details the future story candidates that will roll into the next sprint, prioritizes them, makes them visible to the team, sets up the grooming meeting, and breaks down the stories further if necessary. The product owner does this until the team understands the established acceptance testing (Definition of Done), which will mature sprint to sprint or during individual sprints. The product owner revises, eliminates, consolidates, and decomposes stories.

Learn that estimates are not final. It is possible that there is insufficient information about certain stories or that members have not used all resources in the analysis of historic information. Visualize all the information possible, uncertainties, risks, etc., and try to eliminate the possible impediments before including these stories in a sprint.

Set clear objectives. Never lose sight of the objectives of the sprint, the meetings, the daily points, and time limits. Always have a moderator chosen prior to the start of any meeting (you may not always have a ScrumMaster).

Do not be afraid of the backlog. Do not be afraid of the backlog items that are lower in the stack. Aim to always identify risks and problems, even when items are low on the backlog. Help the product owner reprioritize to identify the associated risks.

Learn to say "no." We must teach people to say "no" to a story in the middle of a sprint. There must be a compelling reason or a discussion to determine whether something that comes in will produce nothing coming out. Say "no" to a poorly defined, poorly planned, and poorly estimated story. Say "no" to an impossible task or to something that does not add value, thereby achieving no ROI. Show the product owner and stakeholders the value of that no. You are saying it not because you want to but because it is for the benefit of the team.

Avoid poisoning your stories. If we try to cross-pollinate knowledge, to avoid "islands of knowledge," and to eliminate risk factors, we can identify the poison in the stories. We identify the difficult stories, stories that can take us out of our comfort zone, and stories involving a danger (technological risks, difficulty).

Always hold the retrospective. Always strive for continuous improvement. This improvement is derived by inspecting what we have done, determining how well we have done it, and maximizing it. Learn not to fall into the same mistakes over and over again. Inspect and adapt to learn what works and what must change to generate new practices.

Cross-pollinate. Cross-pollinate, share, educate, and encourage teams and individuals involved. Communication, transparency, guidelines listed above, tools, and ceremonies are the Agile values. Promote team spirit, empathy between people, mutual and shared knowledge, and the importance of tools. Support and learn from each other.

Many of the guidelines that I've listed here are common sense, but if you do not share them with another person or do not apply them, you cannot realize their value. It's like those things we see every day on the way to work or to a place we always go; and we do not really "see" them until we step back and look clearly, with a new perspective.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.8 (6 ratings)

Comments

Deepak Joshi, CSP,CSM,CSPO, 7/30/2015 1:20:07 AM
Nice article.
Primitivo Cachero Viejo, CSP,CSM,CSPO, 7/30/2015 2:20:19 AM
Thank you. We are trying to share our experiences from the community.
Rohit Ratan Mani, CSP,CSM, 8/4/2015 4:31:38 AM
Well put.
Tim Baffa, CSM, 8/5/2015 10:28:57 AM
All good points.
Ratna Madhav Burugadda Kandalie, CSM, 8/13/2015 4:01:42 AM
Good points.
Dries Vleugels, CSM, 8/13/2015 4:26:52 AM
Good Hints.
Some of them are known, some of them are new...
Shailendra rumade, CSM, 8/18/2015 2:39:59 AM
Good one & good alternate for daily Question :-)
Nandini Leroux, CSM, 8/27/2015 2:04:41 PM
Useful ideas. I like the alternate questions to move the team away from status reporting.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe