How many of you have worked with someone you simply didnt trust? How did this impact your work?
- Were you less likely to work hard for them?
- Were you less likely to share news with them?
- Were you more likely to complain about them?
If the answer to any of the above is yes, then you can see what trust is important in the workplace.
Even more so, trust is vital during agile projects. Projects can ill afford to have employees not motivated to do their best for their teammates. Likewise, they can ill afford to have team members in the dark to potentially important information.
Scrum Masters do not often arrive on a project with the trust of the team in place. You have to earn it. Sounds good, but how do you earn trust. Below are a few tips to help you gain the trust of the team.
- Tell the truth – sounds simple, but is often easier said than done. Tell the team the truth even when it hurts you. The team needs to know that they can believe what they are told. You are the primary source of information for the team and they need to know that they are hearing accurate information.
- Fulfill your obligations – when you say you are going to do something, do it! You expect the team to do this, so you better be prepared to live up to this standard yourself. This applies to the huge tasks (pushing back on requirements, gathering new resources) as it does to the small and mundane tasks.
- Be available – don’t hide from your team. If the team knows where they can find you, they know that you will be there to help them and the project succeed.
- Don’t hog the glory – everyone likes to be praised, but make sure you let your team be the ones to be praised. Since you are the one often speaking to the stakeholders (and bosses), make sure that you make it clear that the team did the heavy lifting. This will cause the team to get the recognition and they will respect you for not trying to take the credit.
- Be good at what you do – most people think that trust is only your attitude,but it also ties into your aptitude. If the team is to trust you as the scrum master, they need to believe in your ability to perform the job.
Practice these five steps at all times. If you do, your team will trust you more and your projects are more likely to succeed.
Please share other tips you have to build trust with the team.
I will be creating a weekly recap of the articles/news that I found interesting that cover the topic of scrum. Below are the links from the week of June 20th.
Please let me know if there are additional articles that you would like included on the list.
What is a burn down chart?
A burn down chart is a visual representation of the work remaining during an iteration. It tracks the amount of work committed to for the sprint along the vertical axis and the time (usually the 3 or 4 weeks of the sprint) along the horizontal axis. This work can be the number of user stories outstanding, but I prefer to use the number of story points that still have to be completed.
Why should I use one?
You should use a burn down chart so that all project stakeholders (team, product owner, management) can see the progress (hopefully) that the team is making. The chart also allows you to easily see how well the iteration is progressing. If the graph is moving from the top-left to the bottom-right, then work is being completed and your iteration is accomplishing its goals. If the graph is staying even, or heaven forbid moving up, then you know your iteration is in danger of not being successful.
How do I create a burn down chart?
The easiest way to create a burn down chart is to leverage one of the many Excel templates that can be found online. These templates allow you to enter the amount of work remaining for the iteration every day of the sprint. Once you have updated the data points, the graph will automatically update.
When the team is reviewing the backlog and planning their sprint, they will begin to undertake the process of estimating for each user story so that they can define the work that will take place during the sprint.
Many developers and teams have extensive experience estimating how long coding a requirement will take. Traditionally this has taken the form of estimating how many hours it would take to code each requirement…and traditionally this method did not work very well.
Scrum varies the formula by asking that the team assign story points to each user story. These story points are a measure of the complexity of each story. They do not attempt to assign duration to each story, but instead allow a comparison between tasks.
You may ask why you shouldn’t assign hours to a user story. The reason is simple…each developer codes at a different rate. Having the team assign hours to a story assumes that they all can code at the same speed. Also, by estimating the complexity of each story, you have created a way for the team to analyze the stories from a more abstract vantage point. This can help to reduce bias during the estimating process.
For those of you new to Scrum, the term stack rank is an unfamiliar term.
However, to Scrum teams, and Product Owners in particular, stack rank is known..and very important.
Stack rank is the traditional method Product Owners use to rank/prioritize their product backlog items.
When you are adding items to the product backlog, simply associate a value for each item.
There is discussion about what values to use for ranking items, but an effective method is to use a 1 to 3 scale. The scale is as follows:
1 – System/process must support this user story
2 – System/process should support this user story
3 – System/process could support this user story.
Now, prior to each Sprint planning meeting, review/update your backlog and item stack ranks. This will allow the Scrum team to focus on the most important user stories. In turn, this will allow the team to deliver maximum value on the project through all Sprints.
I had a conversation the other day with a coworker about Scrum. She was intrigued by the premise, but had always thought of Scrum as being a tool of IT teams. I explained to her that Scrum is not only applicable to IT teams, but to teams working on all types of projects.
Project management in general was initially used by construction teams and engineers. It later became adopted by teams working on projects in every possible discipline. If you were to ask people 25 years ago about project management, most people would respond that it was only for construction projects. Now, if you were to ask people about project management they would reply that it can apply to projects in any area of business.
Scrum, meanwhile, began in the arena of software development. Developers and project managers realized that their projects were not as successful as they should be and were looking for a methodology to improve their chances for success. They discovered that trying to meticulously plan all aspects of a project in advance was difficult if not impossible. This is due to the fact that the requirements and inputs to deliverables are constantly changing. As a result, Scrum and other agile methodologies were created. They allow for a greater degree of freedom in reacting to change.
This prevalence of change is not limited to software development projects. Any construction team can tell you that clients are always changing their specs (tile vs hardwood, deck vs patio, etc.). Likewise, marketing departments are always changing their marketing initiatives (print vs online vs television). It is this abundance of change that makes Scrum perfect for teams working in any area of a company. Scrum lets you adjust to change quickly while delivering maximum value to your clients.
Now how precisely should you follow Scrum within your team? This depends on your team’s individual situation, but all teams can take some aspects of Scrum and apply them to their projects. Below are some of the features/ideals of Scrum you can incorporate into your next project:
Scrum Meetings
- Conduct monthly planning meetings to determine to tasks/deliverables to be completed that month
- Conduct daily update meetings among team members
- Conduct monthly review/demonstration meetings to show your stakeholders the progress you have made
- Conduct monthly retrospective meetings that can be used to improve processes within your team/company
Scrum Roles
- Scrum Master – person who is responsible for facilitating the project and removing impediments from the team’s path.
- Product Owner – person who is responsible for representing end-users to the project team. Helps to prioritize work.
Scrum Ideals
- Communication is more important than documentation – work with your clients to determine their needs and then work to deliver a product that satisfies them
- Client feedback is better than inflexible requirements – when a client comes back with feedback, don’t immediately dismiss the change. Work with them, within reason, to update the product/process
In conclusion, Scrum has benefits that transcend departments. Just because IT folks developed the process does not mean that it is extremely technical or is only applicable to IT projects. Most projects in the real world are subject to changes in their environment and changes to the project itself. Scrum helps projects teams adjust to change in an effort to deliver maximum value to the client.
Good luck on your next project and hopefully Scrum can help your team succeed.
Imagine the first day of school…waiting with your mom at the bus stop and getting ready to board the bus and head to school. The moment was filled with both eagerness and anxiety. Learning that your team is adopting Scrum can have that same mix of emotions for your team members.
Your team is going from a world where:
- they were instructed step-by-step on how to act by the project manager
- they were given clearly documented rules/requirements
- their parents (project manager) were often judged on successes/failures
To one in which:
- they get to determine their success
- they are forced to collaborate on their work
- they are accountable for success/failure
There is a lot of change involved in migrating from a waterfall to an agile methodology. Some team members are going to be upset because they will think that the shift in methodology is because they couldn’t succeed using the previous schema. Some team members are going to be concerned with how their jobs change. Managing this change will play an integral role in how your team succeeds.
In introducing your team to Scrum, you should focus on the following:
- What Scrum is
- Why your team is adopting Scrum
- What Scrum means to the team
What Scrum is
The first step in introducing Scrum to your team. This site deals with scrum and agile, but the two article below are more directed towards those new to Scrum.
Why your team is adopting Scrum
Next, you need to explain to your team why your company is adopting Scrum. You need to focus on the benefits of Scrum to the team because it is a huge change for them.
- Increased quality
- Improved time to market
- Higher customer satisfaction
- Increased responsiveness to change
What Scrum means to the team
To the team members, Scrum means:
- More power to make collaborative decisions
- Greater visibility to company decision-makers
- Greater chances to make great products
- Potential for greater camaraderie
Remember, moving to Scrum is a big change…and a big opportunity for improvement. Do your best to make your team excited about the new process.
Like many who have wanted to learn more about Scrum and Agile Project Management, I have immersed myself in my studies. I have increased my knowledge in the area through books, websites, and other blogs. Below are the links to other resources I have found useful.
Websites
Books
Blogs
Please suggest other resources that you have found useful in learning more about Scrum.
What is a daily scrum meeting?
The daily scrum meeting is a meeting where the scrum team meets to provide a real-time update on project status.
When does the meeting occur?
As the name implies, the team meets every day during the sprint for the daily scrum meeting. The team should aim to conduct this meeting at the same time every day.
How long does the meeting last?
The daily scrum meeting should last about 15 minutes.
Who attends?
The entire scrum team should attend. This includes the scrum Master and the team (developers, testers, etc.)
What happens at the meeting?
During the meeting each team member answers three basic questions:
- What did you do since the last meeting?
- What are you going to work on today?
- Is anything preventing you from accomplishing your goal?
What are the goals of the daily scrum meeting?
- To provide a real-time project status update
- To alert the Scrum Master of any impediments that he/she may have to remove from the team’s path.
I was at a holiday party this past weekend when I began talking with a fellow guest. In a weird coincidence, we were both project managers. Naturally, we began to talk about our jobs and our experience with project management. And naturally, this topic quickly bored the other attendees of the party.
We focused the majority of the discussion on the environments in which we work. He works for a firm that is entirely waterfall in its methodology, while I work for a firm that utilizes both agile and waterfall approaches.
I began to sing the praises of agile, and Scrum in particular, to this person. I talked about how we are able to respond to customer needs quicker, adapt to changing requirements, and deliver a better product.
He stated that all of those benefits sound great, but his company would never allow a team to implement Scrum. I asked why that is. He replied that the management at his company views Scrum as being for lazy teams.
This reply upset me because I know that Scrum often receives this bad rap. Those of us who practice Scrum know that it is not for lazy teams. I explained to him that Scrum is not for lazy team for the following reasons:
- Lazy teams do not self-organize
- Lazy teams do not commit to aggressive timelines
- Lazy teams do not constantly look for ways to improve themselves and their processes
- Lazy teams do not hold themselves accountable
- Lazy teams do not respond to change in a positive manner
Scrum teams constantly do all of the above.
We continued to talk about the myth of Scrum being for lazy teams and he stated that he was going to try and convince his company into piloting a Scrum project. I told him that I would try to elicit more talking points for him to use when discussing the false myth of Scrum as the “lazy project methodology”. So, I ask you to leave a comment stating how you defend Scrum and fight the myth.
