Seven Things I Wish I'd Known When I Started out as a ScrumMaster

16 May 2012

Typically, when an organization starts using Scrum, the person chosen to play the role of ScrumMaster comes from some sort of managerial background. The organization expects that the manager, the so-called "Master," will get the Scrum project delivered because she has managerial expertise — and will handle it along with two other projects she's managing at the same time.

That expectation itself is the first impediment to deal with. Otherwise it's almost certain that the organization won't get the benefits it should out of the Scrum project. Remember, there are no right ways to fulfill the wrong expectations.

I wish I'd known that fact when I first started playing the role of ScrumMaster several years ago. Following are seven more things I wish I'd known when I started out as a ScrumMaster:

 

1. Work on one (and only one) project.

"If you chase two rabbits, you will not catch either." — Russian proverb

Consider this: If you're 100 percent committed, when you choose to work on two projects, you imply that you're only 50% committed to each one. That's a disservice to the organization you serve and to the customers your organization serves, isn't it?

Michael James has contributed a fantastic resource on what makes a great ScrumMaster, and it highlights this point effectively. Here's my paraphrase: An adequate ScrumMaster may handle two or three teams at a time, but the most effective ScrumMaster chooses to handle one team at a time.

Many ScrumMasters know this, but they don't take a stand because it seems like a risky proposition. You're working on only one project, and if that fails, you will be a failure. But that's the whole point. That fear will bring out the best in you and inspire you to bring out the best in your Scrum team.

 

2. Focus on improving team effectiveness.

It's OK if team effectiveness comes at the cost of individual efficiency. Building great software is what matters, regardless of who does it.

In Scrum projects, a focus on individual efficiency is an impediment. Here's the chief reason: To achieve individual efficiency, team members are likely to shy away from practicing Scrum principles, such as transparency and collaboration. For example, if a team member is focusing on achieving individual efficiency, he may choose not to communicate some information that might be useful for the project so that he can use that information to prove that he's more efficient than other team members.

Reflect on the quote written by author Margaret Carty: "The nice thing about teamwork is that you always have others on your side." It resonates with one of the prime Agile principles: customer collaboration over contract negotiation. Inspire your team members to consider every other team member as the customer with whom you all have to collaborate and bring out the desired result.

 

3. Don't manage, facilitate.

This might be a difficult one for a manager, but it's important to understand that Scrum is based on the principle of self-organization that requires facilitation, not management. So any attempt to "manage" the team members is anti-Scrum.

Pete Deemer has written a must-read article on manager's role in Scrum. Below is my take on its basics.

 

What not to do:

  • Don't make decisions on behalf of other team members.
  • Don't assign the work to the team members.
  • Don't keep track of what the team members are doing.
  • Don't incorrectly "own" other team members' work.
  • Don't engage team members in status meetings.

 

What's OK to do:

  • Help remove impediments.
  • Organize one-on-one mentoring sessions for the team members.
  • Give input about how to make features better.
  • Collectively participate in hiring new team members.
  • Help plan team members' career development activities.

The manager's role is concerned with doing things right and complying with the standards, whereas the facilitator's role is about doing the right things and creating the product. These roles require different types of skills, so get convinced that facilitating is what you want to do — or explore non-Scrum work options.

 

4. Establish a "work-life balance" as early as possible.

Too many people, including Scrum team members, don't know how to live until they interact closely with death. They spend the best of their time chasing what I call fool's gold by neglecting their own health, their relationships, and other important pleasures of their lives.

The result? Burnout, unhappiness, half-hearted work, and, at best, mediocrity.

In order for each Scrum team member to perform at his best, it's important that the work the team members pick isn't too much for them, requiring them to spend long hours and weekends in the office at the cost of their health, relationships, or leisure activities.

The classic book The One Minute Manager, by Kenneth Blanchard and Spencer Johnson, puts it clearly: "People who produce good results feel good about themselves." By ensuring a work-life balance, you help people feel good about themselves.

Someone asked me the other day whether a 40-hour workweek contributes to a good work-life balance. There are no right answers to this question; much depends on the person and the situation. The point here is to figure out a win-win solution for the team and the organization, one that helps the team produce great results.

 

5. Ensure that each team member knows what "done" means.

The problem with the definition of "done" is that it's relative. For the person who carrying out the work, finishing her part of it means she's done. Producing software is a complex activity, however, and it's important that all team members understand exactly what "done" means for the given project.

When a team member says a particular feature is "done," how does he ensure that it's done per the expectation? Agile coach and Certified Scrum Trainer Dhaval Panchal has written a very good article to help teams figure out what "done" means. I'd summarize it this way: The definition of done is a nonstatic, auditable checklist that is influenced by reality. So, as a team, identify what the "potentially shippable state" is for a feature, a sprint, and a release at large. Then commit to accomplish each task per its definition of done.

 

6. If a team member is not thrilled by the project and committed to achieving its purpose, the ScrumMaster is not doing a good job.

Consider the example of an orchestra. All the musicians, along with their conductor, work in sync to achieve a common goal: to produce great music. If even one person is out of sync, the resulting music isn't good, much less great. Scrum teams are no different. All Scrum team members, along with their ScrumMaster, work in sync to achieve a common goal: to produce great software. If even one team member is out of sync, the produced software feature might be out of order. That's an impediment the ScrumMaster must remove.

 

7. The ScrumMaster is not the boss.

Anyone trying to be the boss of other team members is behaving in an anti-Scrum manner.

Unlike managers, the ScrumMaster is to be a "servant leader." The ScrumMaster is a coach for the team, not the boss. She facilitates the project work in a way that delivers according to the definition of "done."

Although they have some authority over the Scrum process, many new ScrumMasters struggle to play the servant-leader role, with no formal authority over the team members.

Think of the ScrumMaster's role as similar to that of a health coach, who helps you follow an overall health routine, including establishing good eating habits and exercising properly. A good health coach will inspire you to learn about the benefits of healthful activities, such as eating well, exploring yoga, getting other regular exercise, and so on. In fact, however, the health coach has no formal authority. He can't force you to follow a routine. Instead, he must connect you with the health commitments you've made to yourself.

The ScrumMaster too is expected to make a difference while not having any formal authority over team members. That requires a 360-degree change in the mind-set of some, and it can be difficult for newbie ScrumMasters. But it's said that opportunities come wearing the masks of difficulties. So make a correct choice, and give it your best and most thoughtful try.

 

In summary

If you're aware of these suggestions and you're still not able to practice them in your Scrum projects, there are some gaps in your understanding or execution. But remember, these gaps are nothing but opportunities for you to shine as a leader, beyond whatever title you hold in your organization. Go make that change happen.

Article Rating

Current rating: 3.8 (4 ratings)

Comments

Xiurong Fang, CSM, 5/16/2012 3:45:01 AM
Very good article
Utpal Vaishnav, CSM, 5/16/2012 4:38:02 AM
Thanks Xiurong!
Han van Loon, CSP,CSM,CSPO, 5/16/2012 5:47:11 AM
Hi Utpal, a very nice article.
I learnt long ago that being a leader has little and oftimes nothing to do with being a manager. I once became leader of a departmental team while their manager and remained their leader a long time after I have moved job and office to another country. Their new manager was definitely not their leader and I had to find ways to reconcile the stand-off this person created. Part of my experience that went into the STARS methodology I created.
Han
Maureen Kearns, CSM, 5/16/2012 10:31:20 AM
Utpal, Thank you for the thoughtful reminder. Your article helped re-focus me while planning for an upcoming project. Best wishes for continued success. ~Maureen
Utpal Vaishnav, CSM, 5/16/2012 1:08:02 PM
@Han Van Loon: Thanks for stopping by and commenting. You're right. Managers focus on climbing the ladder efficiently whereas Leaders ask: Is this the right ladder to climb?

I checked STARS methodology page and you have mentioned it so nicely. Building great organizations require great human involvement. And creating great human involvement requires great leadership - keep up the great work!

@Maureen Kearns: Thanks. I'm glad to know this article helped you. Best wishes for your project's success.
Harinkumar Koshti, CSM, 5/30/2012 1:16:12 AM
Utpal,
On "Work on one (and only one) project."
I believe it is also depend on how much an Organization has experience on Scrum practices. Because if its fresh in adopting Agile way of project execution then i believe there will be many impediments to clear for a scrum master and in that case that will be a full time job for him or her to execute the project. but if Organization is mature and adopted Agile methodology then i believe it will be relatively less problems and Scrum master can take care of multiple assignments.

Also i believe its depends on the project type: when i say a project type means, if Project is Risk seeking project then Scrum master might have more jobs to do.
Utpal Vaishnav, CSM, 5/31/2012 3:07:09 AM
Thanks for stopping by and expressing your views Harin.

Agreed that working on one (and only one) project is dependent on organization's experience in Scrum practices, however, in a little different way.

Organizations that do not have ample experience of Scrum sometime fail to recognize that ScrumMaster has to do a full-time job. But, a great ScrumMaster chooses to say "No" to multiple assignments. While this is practically challenging in some organizations, it is the key differentiator from good to great.

For example, consider if a ScrumMaster is working on two projects and in order to resolve an impediment in one project, he has to spend his whole day or several days. Obviously the other project will suffer. At his best, the ScrumMaster will be able to devote 50% of his time to each project, isn't it?
Also, when impediments are not resolved in timely manner, it frustrates the team members and produces not-so-positive outcomes.

I have seen that organizations which get maximum benefits of Scrum prefer that a ScrumMaster is working on one project. Having said it, it cannot be considered as a rule, just the most effective ScrumMasters stay away with multiple projects at a same time.
Savita Pahuja, CSP,CSM,CSPO, 6/6/2012 2:04:51 AM
Very good Article..
Any one could be scrum master who has knowledge and skills whether a project manager, tester, developer ....

Utpal Vaishnav, CSM, 6/6/2012 10:57:12 AM
Thanks Savita for your comment. Each one of us has a power to become whatever we wish for including a ScrumMaster. For some profiles, it might be difficult but NOT impossible. Right actions matter.
Josh Smith, CSM, 6/6/2012 9:32:33 PM
Any advice on how to balance three roles? My organization wants me to play ScrumMaster to the team, formal manager to the team, and Team Member.

This seems to create alot of conflict between the roles I am expected to play, and it's creating me alot of frustration.
Walter Ries, CSM,CSPO, 6/7/2012 10:56:19 AM
@Josh - I am in a similar situation, but I play Product Owner and Team Manager. What helps is for me to communicate which role I am playing when talking with someone. I'll say, "As the Product Owner, I am expecting..." Or "I'm putting on my manager's hat now."
Also, our ScrumMaster is also a team member, but we reduce their capacity for development work due to the additional work on removing obstacles.
I see your biggest obstacle on balancing Team Member and Formal Manager. Just because you are manager, doesn't mean you should not "do any work", but as manager you should be more focused on helping the team to accomplish the work. For the manager, the focus is less on what he does and more on what the team does.
Hope this helps.
Josh Smith, CSM, 6/7/2012 11:34:41 AM
Thanks for the feedback. I see the Product Owner and Team Managers much more closely aligned than Team Member and Team Manager.

The struggles I am seeing is that my job as manager is in a big part to push to keep things moving and on-schedule. But that creates problems where the team isn't willing to report delays or obstacles in terms of their sprints as they are still under the old view of "don't tell your boss you can't get it done". I have tried a number of things to break that habit, but none have taken hold.

The result is that when I do hear about obstacles its way to late to do anything about them, and we are left with no option but to de-scope the sprint.

Combine that with push from upper management to use "Scrum But" and it creates a very difficult situation for me in all of my roles, as well as for the rest of the team.

If anyone has specific recommendations or experience with this, I would love to hear it.
Carlos Colon-Maldonado, CSM, 6/7/2012 1:18:52 PM
This is a well organized article; good job! My only feedback is that your analogy in item number six is not accurate. There is a difference between a team of members that perform specific-independent tasks that, together, produce a product versus a team of equally-capable members (such as a Scrum development team) that perform a list of production tasks equally well. This is why a Scrum development team does not have a head and, therefore, do not need a Scrum master to make decisions on their behalf, assign them work, track what theyΓÇÖre doing, or ΓÇ£ownΓÇ¥ any of their work because it is in essence the entire teamΓÇÖs work . These are some of the points you listed in item number 3.
If a team member is not thrilled by the project and committed to achieving its purpose, the Scrum Master should not have allowed the Sprint to begin in the first place. If this was found afterwards, it means that the unreliable team member should become an impediment and be dealt with by his immediate supervisor to resolve that impediment, not the Scrum Master.
Utpal Vaishnav, CSM, 6/8/2012 1:54:55 AM
@Josh Smith: Your situation is not too uncommon in Command and Control powered world. Many organizations who want to grab the benefits of Scrum but choose to push "Scrum-buts" for all valid looking reasons, unavoidably face such type of situations to an extent. So the short answer is: when you are a part of something that is essentially not Scrum, but known as "Scrum" in your part of world (a.k.a. your organization), there are no Scrum-suggested right answers. However, there are ways to deal with the situation you mentioned.

One way is: when you engage in your organization's version of "Scrum-but", do it the best possible way :).

List down your roles. Under each role, find out what exactly is expected from you. Now, prioritise your roles based on importance of expectation. Most important expectation first and so on. Then get buy-in from your Reporting Head on the expectations. So, your role wise expectations list will become your "True North" and guide you about what is right or wrong in your world. Based on what you have mentioned, I understand that your "Formal Manager" role has supremacy over the other roles. And, in your that role, you are expected to "push" your team members to get things done. So that might be true for you. Sure, it implies that your team members will stay away from transparently communicating the internals with you but it is what you're choosing and when you make choices you own consequences, isn't it?

Another and possibly best way is to take the road less travelled.

Communicate with the management of your organization and put your best efforts to educate them on right way of using Scrum. Outline the benefits that Scrum will provide to the organization. Outline the possible damage that Scrum-buts will make. Give real-life examples. Take advice from Scrum Industry experts. Get a buy-in to use right version of Scrum or don't choose to use Scrum. Now, this is difficult and risky path but this path has power to make you "fly" in your career. Let me know what you think.
Utpal Vaishnav, CSM, 6/8/2012 1:56:50 AM
@Walter Ries: Thanks for your initiative of answering JoshΓÇÖs question. I appreciate it. The way you suggested is a good way of handling the situation. However, it depends on how you are using Scrum for your project. Presuming you're not using Scrum-buts, you can give due importance to the roles you are playing. For the external world, your title can be the "Team Manager" and for the team, you can play the role of just a "Product Owner" and work with ScrumMaster to make the team self-organizing. Because, when you try to "manage" a Scrum team, often, people don't feel thrilled to do their work and their level of "ownership" decreases.
Utpal Vaishnav, CSM, 6/8/2012 2:01:34 AM
@Carlos M. Colon-Maldonado: Thanks for your remarks. I see your point of view.

My $0.2: Each Scrum team member is expected to be his or her own "head" given the team is self-organizing. Now, on the "thrilled" part of the thing: ScrumMaster has to take initiative and make sure that the team members are thrilled about the project. Non-thrilled team members hardly make a great Scrum team.

You provided good examples about "how" to handle the situation when team members are not thrilled. Scrum is a framework and doesn't focus much on how part of the things but focuses more on principles. This is because, in specific cases, different types of "how" may be correct. So, in principle, ScrumMaster has to be instrumental in removing the impediments.

So, it doesn't matter in specific case who removes the impediment, only thing matters is that the impediment is removed. ScrumMaster has to become instrumental in removing the impediment. If he's NOT doing that, he's not doing a good job.

Thanks again for bringing in different point of view. Such discussions through good light on the issues and of good help for the whole Scrum community.
Carlos Eduardo dos Santos Nunes, CSM, 6/13/2012 10:44:23 AM
Fine article! Good Job!!!!!!!!!!!!!!!!!!!
Utpal Vaishnav, CSM, 6/13/2012 11:08:50 AM
Thanks Carlos!
David Lowe, CSP,CSM, 6/15/2012 11:18:26 AM
Nice post, Utpal.

However, I'm not sure about your "Don't keep track of what the team members are doing." Although I agree the SM shouldn't be overbearing, doesn't he/she need to do this to keep the burndown chart accurate?
Utpal Vaishnav, CSM, 6/15/2012 12:45:24 PM
@David J. Lowe: Thanks for your complement and comment.

In a Scrum project, true measure of success is working software, not even the turndown chart. Regardless, ScrumMaster's job is to ensure that the team members are able to self-organize. Needless to say that self-organized team will keep track of what they're doing, isn't it?

So ScrumMaster has a bigger role to play. Rather than giving the team members a fish (keeping the turndown chart accurate), he has to ensure that the team members learn how to fish (so that the team members can keep it accurate).
David Lowe, CSP,CSM, 6/15/2012 12:56:29 PM
I agree in all of the roles you state but ... it's still the SM who's tracking burndown. But, look, I'm being pedantic and the gist of your point still stands: "don't be a jobs-worth and track too much" (ie daily stand up should be enough to ensure estimates up-to-date).
Utpal Vaishnav, CSM, 6/15/2012 12:59:51 PM
You've got a point, David. My view of Scrum says that it doesn't matter who does it but it matters what is produced. And the ScrumMaster is effective when he's putting his/her energies in the right things.
Arif Sayyad, CSM, 6/20/2012 6:17:41 AM
Very Helpful Article !
Utpal Vaishnav, CSM, 6/20/2012 12:51:41 PM
Thanks Arif your comment. I'm glad you find this article helpful.
Phyllis Kenny, CSM, 7/13/2012 6:30:44 PM
Excellent article. Thank you very much. It was very helpful for me. AND the comments were very helpful too.
Utpal Vaishnav, CSM, 7/14/2012 12:35:19 AM
Thanks Phyllis for your comment. I'm happy to learn this article was useful to you. I have experienced that Scrum has power to make us better individuals who don't need titles to make things happen.
Thomas Deiler, CSM, 8/9/2012 7:30:49 AM
@Utpal: I agree with all the topics you wrote about, except one small thing of point 6: "If even one team member is out of sync, the produced software feature might be out of order. That's an impediment the ScrumMaster must remove."
To solve this impediment the ScrumMaster needs to have knowledge about the "one out of sync". How to known this? Either the team members tell him or he figures out himself. In the first case he has to trust the others and by doing this he will be their instrument. In the other case he has to measure the working result to find out which team member was asynchronous. Regardless that this action takes time, it could be beyond the ScrumMasters ability who necessarily does not need to have technical skills. My recommendation for this situation: empower the team to solve this impediment. Let them also care about the uncomfortable things during team life and let them take responsibility for leading/coaching of team members.
Utpal Vaishnav, CSM, 8/9/2012 12:54:46 PM
@Thomas Deiler: Thanks for stopping by and expressing your thoughts.

I see your point of view. The recommandation you mentioned exactly states what I mean by "That's an impediment the ScrumMaster must remove." Empowering the team to do the right thing - as you have mentioned - is actually a part of ScrumMaster's impediment removal process.

It is not always necessary and possible that the ScrumMaster has got all the skills to remove the impediments that come her way. But the point is: she has to lead without title, take responsibility of the situation and inspire respective persons to make things happen. For example, consider this impediment: Because of a system failure, payroll will be processed 4 days later and hence salaries would be delayed by 4 days. A key team member has house loan installment to pay. Since the key team member is stressed fearing what will happen if he miss the instllment date, he's not able to concentrate.

Now in this situation, the ScrumMaster has almost no expertise or authority to resolve the problem with Payroll department. However as an effective ScrumMaster, she may choose to communicate with respective persons and figure out the alternative methods by which the key team member's loan installment issue can be resolved.

The essence as I see in point #6 is: If anything is going wrong with any of the team members and s/he is not able to focus on the work s/he has committed, ScrumMaster has to take the right actions and remove (or inspire other to remove) the impediment.
Mithun Vaidya, CSM, 8/16/2012 3:45:48 AM
Hi Utpal,
Thank you for sharing your thoughts in this wonderful article. Is it "OK" for scrum master to resolve people conflict within the team ? It seems to me that this is not under the role of scrum master but ultimately people conflict within the team is going to affect the Entire team and so the product.As a scrum master, should i intervene and try to resolve the conflict ?
Thanks
Utpal Vaishnav, CSM, 8/16/2012 12:19:09 PM
Thanks Mithun for the praise.

ScrumMaster's chief job is to facilitate team in a way such that team members are inspired to focus on accomplishing what they have committed. So that way, impediment removal is chief expectation from a ScrumMaster. Now, whether to solve the people conflict yourself or get it resolved by someone who is recognized by your organization structure depends upon your senior management's buy-in into Scrum. Bottomline is, as a ScrumMaster, you should take right steps to resolve it. It doesn't matter much how you achieve it.
Arun Balasubramian, CSM, 9/12/2012 4:15:16 PM
Interesting article. But then to realize its worth you should have gone thro' all that.:-)
Too often organizations expect a PM to be SM which is where I believe the conflicts of multiple projects arize.
Utpal Vaishnav, CSM, 9/12/2012 9:22:56 PM
Thanks Arun for your comment. If organizations are doing Scrum for the sake of doing Scrum then it may not be worth. More important, Scrum is not like always-good kind of answer to all the problems. Also, one should use Scrum if it is the right fit for the need. For example, have a look at this: http://www.scrumzen.com/beware-of-scrum. Principle is simple: if it is not worth, don't do it. If you think you HAVE TO do it but it is not worth, it is a matter of a another kind of realization :)
Khushru Doctor, CSM, 11/1/2012 5:29:51 AM
Great article Utpal.

But I would add 2 more here

1. Do not implement Scrum unless the whole team is trained on the SCRUM process.

The complete team should be trained on the process and should not be rushed into working on SCRUM based project unless thoroughly trained on the projects. They should understand the essence of SCRUM.

2. When creating artifacts like Burndown Charts we are more worried about what work remains to be done rather than what has been done.

This is a large paradigm shift. In traditional Project tracking methodology people are more worried about the work done as well as what remains to be done, but in SCRUM we are only worried about what remains to be done. So the people will have to chnage their thought process.
Utpal Vaishnav, CSM, 11/3/2012 3:30:52 AM
@Khushru Doctor: Thanks for taking time and adding your comments. I agree with both of your points. There is a an interesting possibility though about point #1: If the Scrum Coach knows her job well then she can teach Scrum to the whole team using Scrum itself. Now, that's the object oriented way of doing that and not all coaches would like to do that. I have had that
experience when my Coach taught me Scrum in a project in which he played the role of a
ScrumMaster and I played the role of a team member. But it is just one way. Bottomline is
each and every person who are part of a Scrum team, must understand fundamentals of Scrum.
Regarding point #2, I cannot agree more that it is a paradigm shift and that's why it is
becoming harderin environments of our kind. It becomes even more challenging when the same
person has to work on Scrum and non-Scrum projects. Unlearning is much harder than learning
and that's why Scrum is challenging in the beginning. But when there's a will, there's a way.
And such a will has to travel top-down path :). On the personal front, I think I know you.
One of your x-colleagues has been my close friend and I remember he giving your reference
in one of the discussions. Thanks again for adding to the conversation. I appreciate it.
Yogesh Shinde, CSM, 12/14/2012 8:23:28 PM
Good one Utpal. Thanks for sharing.
Utpal Vaishnav, CSM, 12/14/2012 8:54:34 PM
@Yogesh Shinde - Glad to know that you liked it. All the best.
Madhuri K R, CSM, 1/1/2013 11:36:41 PM
Nice one.
Glen Wang, CSM, 2/18/2013 2:13:01 AM
Utipal,

One Scrum Master One Team is just like One Mother One Family. In reality there are two impediments to prevent it happen. (1) An organization especially leaders don't understand Scrum Master's responsibilities. (2) Scrum Master is also evaluated by her boss regarding her performance. Boss doesn't understand Scrum and thinks high performed Scrum Master can serve more teams.

Thanks,

Glen Wang
Utpal Vaishnav, CSM, 2/18/2013 3:30:55 AM
Thanks Madhuri.
Utpal Vaishnav, CSM, 2/18/2013 3:34:46 AM
One mother, one family...what a nice analogy!

You have got it right. In order for Scrum to be really effective, it has to not only have top management buy-in but also deep understanding of its evaluation techniques.

While expecting ScrumMasters to serve more than one team is not uncommon, it is one thing that can deeply influence the overall quality of developed software.

I appreciate your comment and thoughts that you expressed here, Glen.
Francesco Pratolongo, CSM, 4/23/2013 5:21:47 AM
Thanks for article, very interesting and very true. I learned those points essentially by failing: when I started working as a SM I was responsible for 3 projects/teams and I was trying to manage them rather than coaching them. Now after 3 years I have one team working on one project and I never tell them what to do: I just empower them in making the right choice and they rarely pick the wrong one
Utpal Vaishnav, CSM, 4/23/2013 11:43:50 AM
@ Francesco Pratolongo: Thank you for your comment. More often than not, such things are learned by personal experience only. I'm glad you figured out the right thing to do. All the best!

You must Login or Signup to comment.