Agile: Tips for Running An Effective Scrum Meeting

1. Keep the meetings on target

The first step towards an effective Scrum meeting is making sure that the meeting stays on target. In order to do this, the only subjects that should come up during this time are what each individual team member is working on as well as the issues they’re struggling with.
In order to get this information across, many suggest that each team members stick to answering these three questions, and only these questions, during the daily Scrum.

1. What did you do since the last meeting? Team members comment on whether or not their commitments from the previous day were met.

2. What will you do today? Team members explain what they’re working on today and will have done by the daily stand-up tomorrow.

3. What issues do you have? Team members explain where they are running into trouble with certain aspects of the project.

Your team should answer each of these questions when it is their turn, and they should do so without your prompting. If they do miss one of the questions, make sure you get an answer before moving on to the next person. Only by answering all three questions will the team have a true understanding of what everyone is doing.

2. Meetings should not be about problem solving

One important thing to note is that for the daily Scrum meetings to be effective, problems can’t be solved during the meetings. While the third question brings issues to the forefront, these issues may not affect the whole team. As a result, spending an excessive amount of time discussing these issues with everyone is not a productive use of team time. Call “parking lot” and table the issues for the time being. After the daily stand-up, schedule a problem-solving meeting with the individuals who these issue effect. Such an approach will allow for targeted issue resolution.

3. Team members should be prepared ahead of time

As mentioned in the discussion of the three questions, your team members should be able to answer those questions without your prompting. In order for this to happen, you must outline what you expect to hear from your team every day. Once you set those expectations, your team members should come prepared with answers on a daily basis. Reward those who do, and take aside those who don’t. Explain how being prepared with these answers helps the team, and ultimately the project, stay on track.

4. Make the meetings short

Daily Scrums that run too long aren’t effective. People get distracted, stop listening, and ramble on for far too long. Your team then begins to resent these meetings, and communication breaks down. That’s why limiting your meeting time is so important. The shorter they are, the more likely people are to pay attention and find them necessary.
For an effective meeting, the daily stand-up should run about 15 minutes. Some use the formula of 2n + 5 minutes where n is the number of individuals on your team. Either way, by sticking to the 3-question rule, your team will get all the information they need within these time restrictions.

5. Stand Up Meetings

Some believe that, by forcing everyone to stand during the daily Scrum meeting, the meeting is more likely to stay on target and on time. And let’s be honest, the reasoning is solid. No one wants to stand around for an hour just talking.
By asking your team to stand, you’re showing a commitment to staying on task, and your meetings are more likely to be effective because of it.

6. Don’t wait for everyone

Did you say that the Scrum meeting started at 8:30? Then start it at 8:30. If you wait for everyone to show up, you’re wasting time and the meeting automatically becomes less effective. Start the meeting when you said it would begin, and allow people to trickle in.
This doesn’t mean that you should allow people to get away with showing up late though. Offer incentives for your team to show up on time, or embarrass those who showed up late. Ask anyone who comes in after the meeting start time to announce why they were tardy. No one likes to be called out repeatedly for being late. Other option? If they’re not on time, make them wear a dunce hat for the day. It’s not a fashion statement that everyone’s comfortable with.

7. Make sure the meetings are daily

When you’re running daily Scrum meetings, make sure that they’re just that – daily. This is important for consistent communication between team members about what is and isn’t being accomplished.
If these Scrum meetings are run infrequently, minor issues tend to be overlooked, pile up, and amount to larger issues down the road. Consistent communication is key to making these meetings as effective as possible in getting the program running.

8. Have Rules About Who Speaks and When

During the Scrum meeting, only one person should be speaking at a time. They should have the floor, and only be interrupted when they’re getting off of topic. (Oftentimes, when they do, someone will yell “Rat Hole” as a reminder to stay on topic.) Allowing people to speak freely ensures that everyone is heard and that there is no miscommunication.
Along these lines, only the ScrumMaster and team members should be speaking during the daily stand-up. While stakeholders are more than welcome to attend, any issues they have should be taken up with the ScrumMaster after the meeting has adjourned. Allowing more than the vital team members to speak almost guarantees that the meeting gets off topic, and runs much longer than necessary. You are more than capable of presenting a stakeholder message to the team.

9. Remote workers should be part of the daily Scrum

Just because remote workers aren’t physically there with the rest of the team, this doesn’t mean that they shouldn’t participate in the daily Scrum. They can conference call in, or even better, video chat during the daily stand-up. Of course, there are logistics involved with planning this, as you have to take into account several time zones. Make sure that you’re not asking a team member to participate in a Scrum meeting at an unreasonable time (as in 3 AM their time).
Keeping remote workers involved is good for team morale, as well as for project advancement. Asking them to dial in once a day ensures that your team is working as a team, and that issues are addressed.

10. Don’t let your team focus on the ScrumMaster

While the ScrumMaster is running the meeting, this doesn’t mean that the team members should only look at you  when speaking. They need to be looking at their team, as this is team communication time.
If you’re a ScrumMaster who notices that your team is speaking to you instead of their other colleagues, step back from the circle, and stand off to the side. This will force your team to speak to one another instead of you. The project will then take on more of a communal feel, communication will increase, and the meetings will be more effective.

11. Meetings should be tech free zones

As tech professionals, we’re all attached to our devices. The daily Scrum meeting is one place you have to enforce the parting of ways though; don’t allow your team to bring their laptop or phones to the meeting. We know just how easily it is to get distracted by these devices, and an effective Scrum meeting will never occur while people are playing Angry Birds on their cell phones.
At the end of the day, the keys to running an effective Scrum meeting are ensuring that your meeting stays on track and on time. In order to do this, have rules about what can and cannot be talked about, make sure that your team members communicate with one another, and that technical devices aren’t welcome. If you do these things, your daily stand-ups will be more effective, and you’ll help produce a better product because of it.

Agile: Daily Stand-up

What are daily stand-ups?

Daily stand-ups is adopted by agile team to provide a status update to team and to continuously improve the team velocity by meeting up daily and talking about:

• What were accomplished since the last meeting.
• What will be taken up before the next meeting.
• What obstacles are preventing progress.

How to make the daily stand-ups effective?

If not given proper attention to the daily stand-ups it would end up being just a waste of time without any value to the team or the project. It is always nice to talk about the effectiveness of the stand-ups so as to make it more interesting and generate value to the team and the project. Few tips to make the stand-ups effective are:

• Stand up. Do not sit and do the daily "stand-ups"
• Each member should time-box the status update to 30 - 60 seconds.
• Stick to the point and take lengthy discussions separately.
• Conduct stand-ups same time and place every working day.
• Avoid postponing stand-ups.
• Better to choose a place near the workstation unless it do not disturb other teams and avoid meeting in conference rooms. This is to avoid situations where the conference room is already occupied and delay the meeting.
• Each member take a few minutes preparing what to say during the meeting.
• Everyone should be on time.
• Pass around a token (e.g. a soft ball) so that the holder gets the turn to talk.
• Let the member choose an appropriate time to conduct the daily stand-up.

Who should attend the daily stand-up?

Ideally everyone involved in the team should attend the daily stand-ups. If it is the inception phase of a project, it would be really good if the stakeholders could also attend the daily stand-ups. If not everyday, weekly involvement would help them know the progress of the team. It also helps the team get constant feedback and know about new initiatives and promotions taken by the stakeholders that might impact them in one-way or the other.

When do daily stand-ups become inevitable?

Stand-ups is a really nice practice that motivates and pushes the team forward, but sometimes it just becomes the most wasted time of the day even if you are doing it right. The reason could be that it is done by a relatively small team where everyone share the same work-space and know what the other person is up to. The team could collectively decide to do avoid the daily stand-ups and do a weekly iterations instead.

Stand-ups becomes inevitable when:

• A team member spends significant amount of time in other projects.
• Team are spread across departments or location.
• The team size is pretty large (6 and above).
• Inception of the project where there are lots of unknown variables.
• There's lots of confusion within the team.
• A new member joins the team and is not aware of the work done by the team and also help in knowing other team members.

Agile : Nice Chart

Agile: Scrum Roles and Responsibilities

Agile techniques have become very popular and effective approaches to delivering benefit on a project.  For this reason, we will focus on Agile frameworks, techniques, principles and ideas as well.

Agile SCRUM is one of many Agile frameworks.  SCRUM is a very specific framework that focuses on the following roles.

1. ScrumMaster
2. Product Owner
3. Team
4. Stakeholders

The following graphic depicts each role and the relationship of the role with the other SCRUM roles.

A depiction of the SCRUM roles, each roles primary responsibility and its relationship to the other SCRUM roles

The ScrumMaster Role

The ScrumMaster, despite popular belief, is not the Agile term for a project manager.  In fact, the ScrumMaster serves a very different purpose.  The ScrumMaster does not have responsibility for delivering the project.  Rather, the ScrumMaster is a facilitator, coach and champion of the Scrum framework and process.

The biggest challenge to applying Scrum within an organization is not the actual Scrum process.  It is the cultural change and acceptance of the new roles that an organization finds most difficult (e.g., the enhanced power of the Team to commit to a Sprint goal, and to deliver it with little interference from “management”).  More on the differences later, but because the organization does need to accept a significant change in philosophy, there is a need for a ScrumMaster, who serves as the coach, mentor, facilitator, champion, and cheerleader.

Adopting Agile Scrum framework is as much about a change in philosophy as it is a change in processes.  This is because Agile Scrum places distinct responsibilities on each of the roles.  Agile Scrum does not allow anyone to play more than one role.  And the tension among the roles is there for a reason — almost like a balance of power among the roles so that no one role has an unfair authority over the other roles.

It is for the above stated reasons that a full-time ScrumMaster is recognized as the authority on Scrum and needed to continue to facilitate and champion the process, to ensure that the process is followed as intended, and to coach members as needed.

Specific ScrumMaster responsibilities include the following:

• Communicate the value of Scrum
• Teach the organization on Scrum to maximize business value
• Facilitate Sprint Planning, Daily Scrums, Sprint Reviews and Retrospective Meetings
• Create the Task Board and Sprint Burndown Chart at the start of every Sprint
• Attend all Scrum meetings
• Preserve the integrity and spirit of the Scrum framework
• Maintain the focus of the Team
• Make the Team aware of impediments and facilitate efforts to resolve them
• Serve as a coach and mentor to members of the Team
• Respectfully hold the Team, Product Owner and Stakeholders accountable for their commitments
• Continually work with the Team and business to find and implement improvements

The Scrum Team (Team) Role

The Team is ultimately responsible for committing to a Sprint goal and promising to deliver it within the timeboxed Sprint.  The Team is self-managing and self-organized.  The Team works with the Product Manager to determine what items from the Product Backlog they can deliver in a Sprint.  They Team decomposes the Product Backlog into a series of activities that must be accomplished as part of the Sprint.  Since the Team commits to the Sprint, they must ensure that they can deliver on what they promised.  Sprints cannot be extended or delayed.  So the Team wields great power, but the Team is also held accountable for delivering on their commitment.

Specific Team responsibilities include the following:

• Commit to, and self-organize, around a Sprint Goal (A Sprint Goal is different from the Sprint activities.  The Sprint Goal is the intended spirit and purpose of the Sprint.  So if the Team realizes in mid Sprint that a required activity for the Sprint is missing, the Team should add the activity to the Sprint so that they can deliver the Sprint Goal)
• Work with the Product Owner to analyze and decompose the Product Backlog items
• Help create and maintain the Sprint Backlog, Sprint Burndown Chart and Task Board
• Demonstrate the product at the end of each Sprint — during the Sprint Review
• Implement action items that come out of Retrospectives (essentially lessons learned)
• Facilitate Sprint Planning, Daily Scrums and Retrospectives if the ScrumMaster is not able to do so for any reason
• Attend all Scrum meetings
• Collaborate and share knowledge and experience among the Team, Product Owner, ScrumMaster and Stakeholders
• Help other members of the Team
• Look for ways to continually improve

The Product Owner Role

The Product Owner is responsible for delivering product value.  This means working with the Stakeholders to understand their needs and developing a Vision and a Product Backlog that aims to achieve the Vision.  This role might be the closest role to a classic Project Manager role.  However, there are still significant differences.  For example, the Product Owner does not control what the Team commits to completing.  The Product Owner prioritizes the list of items on the Product Backlog in sequential order (from 1 to n).  But the Product Owner cannot force the Team to commit to delivering beyond what the Team feels comfortable.  Since the Sprints are timeboxed (usually 2 weeks to 30 day Sprints), the Team is ultimately responsible for defining what they can deliver.

Specific Product Owner responsibilities include the following:

• Maximize business value by the Team
• Maintain and prioritize the Product Backlog sequentially (1 to n)
• Create and maintain the Release Burndown Chart
• Help the ScrumMaster organize Sprint Review Meetings
• Attend Scrum Meetings
• Clearly communicate the business case to the Team and Stakeholders
• Build and maintain a relationship with the Stakeholders
• Support the ScrumMaster to help the Team become self-organizing
• Report progress to the Stakeholders regularly
• Ensure the proper use of corporate resources and assist the Team to obtain resources as needed

The Stakeholder Role

The Stakeholder is anyone who has an interest or stake in the project.  This can be the direct managers of the Team members, the persons providing funding for the project, the Project Manager — yes I said Project Manager.  Combining Agile Scrum with traditional project management is not unusual.  In fact, Scrum does not account for many of the things often required for a project such as project management documents and artifacts.  This might be because of organizational policies and procedures that require a level of oversight that requires specific documents be created (e.g., Risk Management Plan, Quality Assurance Plan, Project Management Plan, Procurement Management Plan, etc.).  These responsibilities still fall under a Project Manager role.

Within the Scrum framework, Stakeholders are responsible for communicating their needs, and providing feedback on the product.

Specific Stakeholder responsibilities include:

• Work with the Product Owner to develop and maintain the Product Backlog
• Attend Sprint Planning meetings as needed to provide feedback and expertise
• Provide direct feedback to the Team during Sprint Reviews
• Remove roadblocks and impediments for the Team, Product Owner and ScrumMaster
• Avoid distracting the Team during a Sprint — after the Team has committed to the Sprint
• Support the Scrum Framework

Agile :Terms are often used in a Scrum process.

Scrum Team

Product Owner, Scrum Master and Development Team

Product Owner

The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders, and ensuring the value of the work the Development Team does.

Scrum Master

The person responsible for the Scrum process, making sure it is used correctly and maximizing its benefits.

Development Team

A cross-functional group of people responsible for delivering potentially shippable increments of Product at the end of every Sprint.

Sprint burn down chart

Daily progress for a Sprint over the sprint's length.

Release burn down chart

Sprint level progress of completed product backlog items in the Product Backlog.

Product backlog (PBL)

A prioritized list of high-level requirements.

Sprint backlog (SBL)

A prioritized list of tasks to be completed during the sprint.

Sprint

A time period (typically 1–4 weeks) in which development occurs on a set of backlog items that the team has committed to. Also commonly referred to as a Time-box or iteration.

Spike

A time boxed period used to research a concept and/or create a simple prototype. Spikes can either be planned to take place in between sprints or, for larger teams, a spike might be accepted as one of many sprint delivery objectives. Spikes are often introduced before the delivery of large or complex product backlog items in order to secure budget, expand knowledge, and/or produce a proof of concept. The duration and objective(s) of a spike will be agreed between the Product Owner and Delivery Team before the start. Unlike sprint commitments, spikes may or may not deliver tangible, shippable, valuable functionality. For example, the objective of a spike might be to successfully reach a decision on a course of action. The spike is over when the time is up, not necessarily when the objective has been delivered.

Tracer Bullet

The tracer bullet is a spike with the current architecture, current technology set, current set of best practices which results in production quality code. It might just be a very narrow implementation of the functionality but is not throw away code. It is of production quality and the rest of the iterations can build on this code. The name has military origins as ammunition that makes the path of the weapon visible, allowing for corrections. Often these implementations are a 'quick shot' through all layers of an application, such as connecting a single form's input field to the back-end, to prove the layers will connect as expected.^{[citation needed]}

Tasks

Work items added to the sprint backlog at the beginning of a sprint and broken down into hours. Each task should not exceed 12 hours (or two days), but it's common for teams to insist that a task take no more than a day to finish.^{[citation needed]}

Definition of Done (DoD)

The exit-criteria to determine whether a product backlog item is complete. In many cases the DoD requires that all regression tests should be successful. The definition of "done" may vary from one Scrum team to another, but must be consistent within one team.

Velocity

The total effort a team is capable of in a sprint. The number is derived by evaluating the work (typically in user story points) completed from the last sprint's backlog items. The collection of historical velocity data is a guideline for assisting the team in understanding how much work they can do in a future sprint.

Impediment

Anything that prevents a team member from performing work as efficiently as possible.

Sashimi

A term used to describe one or more user stories, indicating that they are thin slices of a product feature or capability.

Abnormal Termination

The Product Owner can cancel a Sprint if necessary.The Product Owner may do so with input from the team, Scrum Master or management. For instance, management may wish to cancel a sprint if external circumstances negate the value of the sprint goal. If a sprint is abnormally terminated, the next step is to conduct a new Sprint planning meeting, where the reason for the termination is reviewed.

ScrumBut

A ScrumBut (or Scrum But) is an exception to the "pure" Scrum methodology, where a team has changed the methodology to adapt it to their own needs.

ScrumBag

A ScrumBag (or Scrum Bag) refers to the person, group, or any other blockers that could be a factor for Impediment.

Agile : Scrum Values

All work performed in Scrum needs a set of values as the foundation for the team's processes and interactions. And by embracing these five values, the team makes them even more instrumental to its health and success.

Focus

Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner.

Courage

Because we work as a team, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.

Openness

As we work together, we express how we're doing, what's in our way, and our concerns so they can be addressed.

Commitment

Because we have great control over our own destiny, we are more committed to success.

Respect

As we work together, sharing successes and failures, we come to respect each other and to help each other become worthy of respect.

As an organization applies Scrum it discovers its benefits. At the same time, it sees how these values inherently contribute to the success of Scrum and understands why they are both needed, and bolstered, by Scrum.
  
Individuals and interactions over processes and tools - processes and tools are helpful, but they will do you no good if the team does not communicate and collaborate in a constructive fashion. 


Working software over comprehensive documentation - documentation is important, but what's most important is to have working software. 

Customer collaboration over contract negotiation - you are not just looking to get a contract and get money that way - you are solving the customer's problem. 

Responding to change over following a plan - if the requirements or perceived requirements changed, so should the plans and design.

Agile : Scrum Team

Better way of working

What is Scrum? Scrum is a way for teams to work together to develop a product. Product development, using Scrum, occurs in small pieces, with each piece building upon previously created pieces. Building products one small piece at a time encourages creativity and enables teams to respond to feedback and change, to build exactly and only what is needed.
More specifically, Scrum is a simple framework for effective team collaboration on complex projects. Scrum provides a small set of rules that create just enough structure for teams to be able to focus their innovation on solving what might otherwise be an insurmountable challenge.
However, Scrum is much more than a simple framework. Scrum supports our need to be human at work: to belong, to learn, to do, to create and be creative, to grow, to improve, and to interact with other people. In other words, Scrum leverages the innate traits and characteristics in people to allow them to do great things together.

How does Scrum Work?

Building complex products for customers is an inherently difficult task. Scrum provides structure to allow teams to deal with that difficulty. However, the fundamental process is incredibly simple, and at its core is governed by 3 primary roles.

1. Product Owners determine what needs to be built in the next 30 days or less.
2. Development Teams build what is needed in 30 days (or less), and then demonstrate what they have built. Based on this demonstration, the Product Owner determines what to build next.
3. Scrum Masters ensure this process happens as smoothly as possible, and continually help improve the process, the team and the product being created.

While this is an incredibly simplified view of how Scrum works, it captures the essence of this highly productive approach for team collaboration and product development.

 Scrum Team

A Scrum team in a Scrum environment does not include any of the traditional software engineering roles such as programmer, designer, tester or architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Because of this, Scrum teams develop a deep form of camaraderie and a feeling that "we're all in this together."
Former roles in traditional teams often adapt to an agile role that makes them an integral Scrum team member who retains some of the aspects of their prior role, but also adds new traits as well. New roles in a Scrum team are the ScrumMaster or product owner. You can find out more about which role in a Scrum team would suit you here by finding your pre-agile role.
A typical Scrum team is five to nine people. Rather than scaling by having a large team, Scrum projects scale through having teams of teams. In this way, we have worked on projects with more than 500 people and have consulted on projects with more than 1,000.