Best products from r/scrum

As you're both (you and the team) very new to scrum, you should start with some of the supporting basics that help tie everything together.

You're pretty far from the ideal situation, but there's nothing preventing you from learning and growing together. it's much harder without a careful guiding hand, but not impossible. There's a lot of things you're not going to know/understand simply because you haven't been exposed to it yet.

1. Always begin with why. Why do we have planning. Why do we have BL grooming. etc. by understanding the purpose of each ceremony you will be able to better understand how to execute these ceremonies against the context of your organization.
   
   IE: scrum doesn't have a set way to do these ceremonies (other than loose guidelines. the by-the-book approach) because how they are run is environment specific. Most places are not equipped to do scrum by-the-book exactly. IE: they have QA. and QA is not a role within the scrum framework. The team should clearly define the roles and responsibilities of each team member. These definitions will change over time through the retrospective. every standard, process, etc. should be treated the same way. you should always be verifying that your processes are still valid. As the team matures and grows their needs will change and your processes should reflect that.
   
   
2. The loose guidelines are a starting point. these are not an end-goal. IE: in the retrospective we typically ask three questions: What should we start doing, what should we keep doing, what should we stop doing. you answer these questions in the context of product (what you're working on), process, and people.
   
   However this is a 'crutch' for teams that don't understand the retro yet. this format should eventually change, but you won't have to worry about this for a while.
   
   
3. do everything you can to understand the basics of software development. (IE: things that should be done independently of Scrum) These are things like understanding the 5 levels of estimation, the difference between relative and absolute estimations, why the team needs to establish standards for processes and definitions (IE: definition of done, when should something be a task vs a story), the difference between data and information, roles and responsibilities, etc.
   
   This is the kind of stuff that really differentiates between a scrum master/agile coach and a project manager.
   
   
4. Also understand that Scrum is an agile framework. Just like the 3 question approach to the retrospective, scrum is a stepping stone to becoming agile. If you haven't, you should read the original HBR article about scrum to get a better understanding of the strengths and weaknesses of the framework. this should help you understand the 'why' behind each ceremony and allow you to better make adjustments based on your environment.
   
   6 months to a year from now, what you're doing should look different than scrum by-the-book. I highly recommend you start reading books to help cover the gaps in your understanding. I suggest you start with Phoenix Project and a book on writing user stories.
   
   
5. Think of scrum as a problem finding mechanism and not a problem solving mechanism. This is why the retrospective is the most critical ceremony of scrum. DO NOT WORK AROUND PAIN POINTS. If the team says they feel like they have too many meetings, figure out why. If something took longer than expected, dig into what dependencies were missed in planning and take steps to make sure those aren't forgotten again.
   
   The point of a sprint is to iterate. Yes, we also get shippable increments out of a sprint and that's important, but this pales in comparison to iterating against your product (so you can fail faster and get more value to your customer) and your own development process (this is what will truly enable you to iterate faster and faster as you mature)
   
   This means you will often but heads with leadership, as better development practices often require a shift in culture. Ultimately you want to be able to have autonomous teams that are aligned to the business needs.
   
   -----------------------
   
   Recomended reading:
   
   https://hbr.org/1986/01/the-new-new-product-development-game
   
   https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262509
   
   https://www.amazon.com/User-Story-Mapping-Discover-Product/dp/1491904909/
   
   https://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685/
   
   https://www.mountaingoatsoftware.com/blog
   

Excellent practice of software delivery in Scrum is an extremely difficult skill to master. Don't expect easy answers, but seek out a rigorous course of mastery. Be wary of those who flatter with easy paths to success and cherish those who challenge your ego.

Step one, and don't ignore this:

http://scrumguides.org

This is your first mentor. I recommend reading it once a day for 2 weeks. Ask someone to quiz you on it until you know it back wards and forwards. This is the first form, like when learning a martial art. Think on it deeply and concentrate first on what it says to do. Then just do it. If you have questions, give your sensei the benefit of the doubt and just get good at understanding and executing the basic forms.

After that, explore the "why's" behind the roles, events, artifacts and rules. For reading I recommend:

Scrum: A Pocket Guide

At this stage, it's imperative to find a mentor, someone who has progressed through this "why" stage and can guide you efficiently in this next stage of learning and will help you avoid harmful pitfalls. Look online, in forums, maybe this sub, local meetups, name brand web sites like Scrum.org and keep looking until you find this person. All people will approach this stage of mastery and have the temptation to proclaim, "I've got this!" when they don't. They are on the edge of true understanding and wisdom.

Beyond this is true mastery and expertise. This is where folks tend to write their own playbooks and is beyond the scope of this suggestion. Feel free to reach out to me with any specific questions you may have.

A great Scrum Master recognizes himself in the acronym made up by Geoff Watts, RE-TRAINED:

• Resourceful, is creative in removing impediments
  
• Enabling, is passionate about helping others
  
• Tactful, is diplomacy personified
  
• Respected, has a reputation for integrity
  
• Alternative, is prepared to promote a counter-culture
  
• Inspiring, generates enthusiasm and energy in others
  
• Nurturing, enjoys helping teams and individuals develop and grow
  
• Empathic, is sensitive to those around them
  
• Disruptive, breaks the status quo, help create a new way of working

Yes! We end up here from time to time. This is honestly where i think the scrum masters really earn their keep.

Every situation is different, but IMO it comes down to them regaining engagement with their work and the process. I'd recommend reading "flow" https://www.amazon.com/Finding-Flow-Psychology-Engagement-Masterminds/dp/0465024114 as it has great information on how people get excited with things. At the end of the day it sounds like they are not really feeling it anymore.

Sorry, I don't have better silver bullets, but like others said I would start with being direct in a "safe space" (like no managers or whatnot in the room).

As a scrum master, you are a servant leader. Understanding what that means can take time. It's more than a facilitator and more than a rule keeper for scrum. It may depend on your background on how your first approach to SM will be. You may be experienced managing people or you may be experienced managing projects.

In my experience I found the role of SM put me in the place of a silent observer (or maybe just less loud). I watch the team, I listen to how they talk to each other and I look for areas of conflict. Sometimes you may have to come up with creative ways to get a team to discuss their communication problems.

I try to hold off on my opinion and instead guide the discussions. Encourage the team to challenge each other. Often I can see a solution that will work but I allow the team to come to the same conclusion on their own without forcing things.

Understanding the scrum guide and the rules of scrum are expected, however here are some resources I've found useful over time that go beyond enforcement of the scrum guide:

Five dysfunctions of a team There are also workbooks available for this book that may help you identify where your team fits.

People styles at work or other similar resources and / or workbooks that focus on how people talk to each other. Some others I've spoken with also use Disc or Myers Briggs personality styles. These can be expensive however and usually require a professional to help you in understanding and following though. I found the people styles a cheaper option.

Also I want to add for yourself, you may find 7 Habits of highly effective people to be useful in developing leadership.

Thanks for the resource – bookmarked! I'm currently reading Sutherland's book, it's surprisingly really well written. https://smile.amazon.com/Scrum-Doing-Twice-Work-Half/dp/038534645X?sa-no-redirect=1

Our dev team thinks they work in agile, but they're definitely 'scrum but'. Also it's a sensitive political situation for me. The times I've even remotely showed interest in integrating our teams or getting involved, I've been reprimanded. So unfortunately I don't think my current situation is going to provide much in the way of opportunity to learn hands-on. I'm going to continue to see if I can find a creative solution outside of the dev side, but I'm more resigned to making the change wholesale with a new place. Also, I did sign up for the 2-day training in a few weeks, so I am committed, and hopefully soon, certified.

Curious - what kind of stormy waters have you experienced?

Ok, you can start with some reading in books.

A suggestion: Scrum a Pocket guide - Gunther Verheyen

If you like a good novel (about DevOps): https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592

​

If you going for training, go for PSM 1 first (prefer that your boss is paying :)). This will give you a lot of background theory on Scrum, specially if you participate in a class. If being Product Owner is more suiting late, you have the advantage of having the theoretical background already.

​

Good luck in your journey! :)

Cheers, Johan

Pick up a copy of Mike Cohn's User Stories Applied for a great reference on this topic.

Once you have read that I highly recommend getting a copy of Gojko Adzic's Fifty Quick Ideas to Improve Your Stories (also available on amazon)

You could even roll all of that together and run a story mapping session with your team - this will give them a much broader understanding of what you want the app to do as a whole and you'll get a chance to explain your vision.

EDIT: Hit save early, added story mapping & formatting :)

I think a start with SCRUM requires understanding of roots of this methodology, that is why I would start from reading (or re-reading if you are already familiar with the book) of Doing Twice the Work in Half a Time by Jeff Sutherland.
Then go for the Scrum Guide, it is all there.
I believe that right implementation of SCRUM requires 2 things: discipline (military roots) and shuhari concept from martial arts. In simple words, you need to start doing it step-by-step and it is obligatory to do it by the book, you will not master it in 1 day and SCRUM is always a process of a continuous improvement.

Start with the things that are simple to implement and give the best results:

- working in sprints (1 week is great);
- daily stand up;

- sprint review;

- retrospectives;

- backlog and user stories;

- deliver to production at the end of each sprint;

- focus on 1 user story at a time, etc, etc.


then you can go for certifications: CSM is a good way to start and understand if you want to keep on getting certificates and you would understand that there are many ways to keep on improving your SCRUM further.


don't forget that Jeff Sutherland has a bunch of online lectures about SCRUM @ https://www.scruminc.com ,
someone already recommended to read Mike Cohn, I double that.

Don't be intimidated, it's pretty straightforward to pick up and then become an advanced ScrumMaster over time through experience. I always suggest people start with Ken Schwaber's book, "Agile Software Development with Scrum". Then, ideally, implement a few practices such as a scrum / story board with cards or post-its, a product back log, and daily standup meetings. After a bit of going through the motions, then get CSM certified.

As /u/Imre_R said, six sigma is completely different, but implementing a good process is the common goal. Further, I don't suggest getting into lean / Kanban until you've done scrum for a while. Lean, to me, is more advanced because its goal is to maximize flow of the work and minimize waste, especially across interdisciplinary departments, specifically the whole company. So I recommend reading, practicing, then certification of scrum. Then broadening practices with lean outside your department. However, if someone starts with Kanban and it works for them, more power to them. Kanban is similar to a scrum board, btw, but more advanced workflows.

I'm also open to any questions, I didn't want to inundate you with too much stuff at this point.

Scrum: The Art of Doing Twice the Work in Half the Time is the most important. It is Scrum broken down by the creator of Scrum. It’s filled with some good empirical data and is pretty trade-agnostic. Not super specific for tech work just work in general. If you want a good tech use-case of scrum and agile methodologies The Lean Startup is pretty insightful and convinced me that documenting every detail of a product before developing never works.

I do a set of activities as discussed in Agile Retrospectives by Esther Derby.

Mad, Sad, Glad is a really great activity to focus the team's thoughts and Gather data. However, if you can define a full set of activities to draw insights and then add Spikes/Enabler to your Backlog, it will really help the team. From the time I started doing these activities, the team performance improved dramatically and I have stuck with the template. If you are interested do read about it in an article about the template that I have written.

​

The retro is the key, IMO. I recommend reading “Agile Retrospectives: Making Good Teams Great” by Esther Derby & Diana Larsen. Lots of good stuff there! https://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649/ref=nodl_

Thanks, I kinda figured that the books by Schwaber and Sutherland would provide good material, as it shows their train of thought. I didn't have yours on the list though. For who's interested, other ones by them:

• Software development with Scrum
  
• Software in 30 days

I just finished reading The Scrum Field Guide (version 2) by Mitch Lacey(https://www.amazon.ca/Scrum-Field-Guide-Advice-Beyond/dp/0133853624/ref=sr_1_2?ie=UTF8&qid=1488072378&sr=8-2&keywords=scrum+field+guide)

It was fantastic. Picked it up about 3 months after my team started running agile scrum/XP. The first few chapters actually discussed a few of the issues I had worked through with my team. The rest seemed to address things that hadn't come up yet (some won't, some won't because I'm aware of it now). Definitely worth the buy.

I just finished my PSM II certification. This book is by far the best read you can get if you want to move beyond just being a "scrum nazi" and enforcing the rules of scrum in your organization. It was also the most recommended book from a recent Scrum.org training event I attended: https://www.amazon.com/Scrum-Mastery-Good-Great-Servant-Leadership/dp/0957587406

is this the one?

https://www.amazon.co.uk/Scrum-Pocket-Companion-Practice-Publishing/dp/9087537204/ref=sr_1_1?ie=UTF8&qid=1504106318&sr=8-1&keywords=the+scrum+guide