Top products from r/scrum

We found 44 product mentions on r/scrum. We ranked the 40 resulting products by number of redditors who mentioned them. Here are the top 20.

Next page

Top comments that mention products on r/scrum:

u/Onisake · 2 pointsr/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
u/semperagilis · 1 pointr/scrum

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.

u/felipe0103 · 1 pointr/scrum

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
u/BillOfTheWebPeople · 2 pointsr/scrum

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).

u/CaptHandsome · 2 pointsr/scrum

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?

u/spotty-bag · 4 pointsr/scrum

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 :)

u/wouterla · 11 pointsr/scrum

Magic is the recommended solution.

In Scrum, the team needs to be able to do all the work necessary to deliver. That always, without exception, includes testing. Hiring good testers is not a bad idea. Putting them in a separate team is a terrible idea. Don't do that.

Even if you have some good testers, most of the testing work will still have to be done by the development team. That is because most of the testing work should be in automated, developer, tests. Unit tests. Contract tests. Integration tests. Component tests. Smoke tests. Etc.

If we run into a bottleneck, one of the best ways we have of dealing with it, is to pull the work forward. Any high performing agile team will learn to be good at ATDD/BDD approaches to defining the work. That means involving developers and testers in specifying the work to be done through examples that are a starting point for (automated) functional tests. In this way we specify the tests first, and execution can be by anyone in the team.

Ideally, though, the developers will implement those tests (along with some of the ones mentioned earlier) and in doing so will build up a base regression test suite as the work progresses. There's more to this, but you can easily find out about that. Try Ken Pugh's book and Seb Rose's books.

As for code reviews, those have the same problem: they become bottlenecks. This is why the early XP teams started doing Pair Programming: the same, and more, benefits, but continuously done instead of an after-the-face process stage. Like testing, code review is not an atomic action.

If you keep doing code-review as a stage in your workflow (there's other ways of doing code reviews), you'll understand from the above that a large part of your testing will already have been done, and is automated. Issues found later, either in the code review, or by a manual/exploratory testing step, should be captured in an automated test, and added to the test suite. That way, the type of chicken-or-egg problem you describe just doesn't occur.

TL;DR: the team is responsible for delivering high quality software at the end of every sprint. They need to do all the work that is necessary for that. This includes testing. Testing should be largely automated, and as such is mostly done by the developers. Testing is a skill, and qualified testers should guide your developers in the tests they write. If we run into a bottleneck, we try and pull it forward in time.

u/2901were · 1 pointr/scrum

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.

u/dukey42 · 1 pointr/scrum

Let me recommend Essential Scrum as IMO one of the best books on the topic.

Also just research Lean, Agile and Scrum yourself.

There are tons of free stuff you can read! My handbook is also out there for free.

u/DrinksWellWithOthers · 2 pointsr/scrum

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.

u/recycledcoder · 3 pointsr/scrum

/u/tevert brings up some very good points. I'm going to take a slightly different stance, for the sake of completeness: if estimating is such a pain... why do it? What job are you hiring estimates to do?

The age-old RoI argument is always interesting. Let's take a look it it:

RoI = (Revenue - Cost)/Cost

So in order for an ROI calculation to make sense, Revenue must be expressed in the same unit (yup, dollars will do), and be of the same scale of precision.

So a first interesting question would be: what is the confidence interval and error margin of the revenue estimation? It would be nonsensical to estimate "cost" to a higher precision than revenue: your equation is only as good as the weakest of your measures.

You say you keep track of the time it takes to estimate. This is interesting... is this cost included in your RoI calculations?

Further, what is the impact on team morale and productivity of the estimation process? Is quality preserved in the presence of an imprecise estimation? If not, what is the cost of that?

Ok, I'm done agitating... for an in-depth treatment of these themes, I would point you in the general direction of Vasco Duarte's No Estimates book and Woody Zuill's contributions on #noestimates. Regardless on whether you continue to estimate or not, they bring up excellent points, and their discussion can also make you better at estimating.

Finally, for symmetry's sake, I will point you to one of the definitive books on estimation: Software Estimation: Demystifying the Black Art.

Good luck - it's a tricky, and highly environment-dependent issue. My personal experience favours the "break everything down to 1-pointers, measure flow, project (but don't estimate) based on that"... but this may, or may not, be applicable to your situation and environment.

u/coolcalabaza · 0 pointsr/scrum

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.

u/sm-ash- · 1 pointr/scrum

Scrum masters can come from any background. Having PM knowledge is helpful but not required. A scrum master is a guide and coach for the team. They are responsible for ensuring the team is following the rules of scrum, facilitating their meetings, and overall helping the team on the path to high performance.

Understanding the rules of scrum and the agile principles are more important. In your first SM role you will likely be following the scrum guide as closely as possible but the importance will be in understanding why the practices exist. What is important in the daily scrum? Why do we ask the 3 questions? What is the real goal in that meeting? etc... Eventually guiding and facilitating becomes more about the principles, outcomes, and goals than the rules of scrum but that comes with time.

Pay attention to the people on the team. I suggest looking into some personality or team-working books as a scrum master should be in tune enough to understand the work being done (technical and business purposes) and how the people work together. Conflicts amongst team members can be a difficult impediment to remove.

u/saugatascrummaster · 1 pointr/scrum

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.

​

u/mshaw6011 · 4 pointsr/scrum

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_

u/rvssr · 2 pointsr/scrum

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:

u/RyanRoundhouse · 1 pointr/scrum

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.

u/ZachSka87 · 1 pointr/scrum

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

u/kludos · 1 pointr/scrum

Mike Cohn - User Stories Applied is probably the most practical agile book I've ever read
https://www.mountaingoatsoftware.com/books/user-stories-applied.

Also the OG: Kent Beck - XP Explained
https://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658