(Part 2) Best products from r/scrum

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.

I had bought a book, but honestly just taking the practice tests on the scrum.org site (https://www.scrum.org/open-assessments/scrum-open) over and over was the true help.

If you're a book guy though, here's what I grabbed:
https://www.amazon.com/gp/product/1521475466/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1

I'd give the book 3 out of 5 stars, but for content I'd give it 5/5: it is just sloppily organized and there's some grammar challenges here and there.

I'd recommend taking the assessments over and over until you pass consistently and quickly.

Good luck!

>Thanks for your answer, I do understand that I've got to meet them where they are at and iterate towards a more agile and Scrum specific mode of working.

I feel like there's a 'but' here. :) if you have more questions, please ask.

>You make a good point that while they are not all able to work on everything now, the plan is that they will get there so they may as well work through refinement together starting now.

Transformation isn't instantaneous, so you have the right idea now. change at this scale can be difficult. go for the easy wins and then go for the harder ones later. Remember some of the core tenants of leadership. There are things you should align to and things you should manage. where are you aligning? Is everyone aligned? where are you managing?

A few books that might help you out:

https://www.amazon.com/Drive-Surprising-Truth-About-Motivates/dp/1594484805

https://www.amazon.com/Scrum-Mastery-Good-Great-Servant-Leadership/dp/0957587406

https://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783/

https://www.amazon.com/Implementing-Lean-Software-Development-Concept/dp/0321437381/

https://www.amazon.com/Coaching-Agile-Teams-ScrumMasters-Addison-Wesley/dp/0321637704

I'm leaving a few books out that you have probably read, like Phoenix Project and 5 dysfunctions of a team. If you haven't read these you should. The above books go over a few advanced topics and should cover any gaps you might have in your foundation of knowledge.

> on the product backlog to be prioritized and scheduled, or are those the kinds of things that should go on an impediment list?

Impediments are what make the team move slower. Sounds like Python or Jenkins has little impact on the team's productivity, so they should go in the product backlog. Jenkins related tasks could be considered impediments if the developers end up doing what automation is supposed to take care of.

> we've been actively trying to improve for a while now, but

Try proposing a Team Sprint

> the code is difficult to work with, not particularly maintainable, very complex, quite buggy in places and huge in scope

Working Effectively with Legacy Code proposes installing testing harnesses around modules before altering their implementation.

> Or is it possible for things that are on the impediment list to then also go on the product backlog? When are things on the impediment list worked on? Just when somebody has some slack time?

a Sprint Backlog is a continuation of small items, breaking down a PBI into smaller increments, and it belongs to the development team, not the PO. In this spirit, an impediment can be in the sprint backlog, but not in the product backlog. The scrum master owns the impediment backlog and the development team commits to this in planning (the Daily Standup is for planning, so it's a good time to commit to tackling an impediment).

It seems like your team handles impediments as second-class to PBIs. In Lean/TPS, there's a rule. If there's a choice between a task to be completed, and a task that can remove the blocker/impediment to that task, then by default, choose to remove the impediment first. Swarming and [Andon](https://en.wikipedia.org/wiki/Andon_(manufacturing) help with this.

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

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.

I'm not a product person, but I'm a Scrum Master, so I'm usually helping my POs out. I don't know where you are in your career, so I'll share some things:

Overview of the role: https://www.oreilly.com/ideas/what-exactly-does-a-product-manager-do-all-day-anyhow

Great book for more in-depth info: https://www.amazon.com/Product-Mastery-Good-Great-Ownership/dp/1540562549

This made one of my POs go Eureka the other day: https://blog.usejournal.com/the-lean-startup-trap-e74b27618fc3

And I really like what this PM writes. Lots of good stuff here: https://hackernoon.com/@johnpcutler

Go wild!

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

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

Not sure if this is what you're after, I've used team charters for quite a few teams. It's not in the Scrum guide but it is a recognized agile practice to align the team to a common goal and set out some working arrangements etc

Check out the book Lift Off, it provides a framework and examples to help get you started.

https://www.amazon.com/Liftoff-Launching-Agile-Teams-Projects/dp/097792016X

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

Hi Bowelman,

I used Mplaza to pass the PSM1 a few days ago. From the videos, sample questions and the 3 exams, I scored a 77/80. I also recommend the book below too. I read the authors book on PSM1, which helped me too.

https://mplaza.pm/professional-scrum-product-owner-preparation/

https://www.amazon.com/Professional-Scrum-Product-Owner-Certification-ebook/dp/B01D73SRH4/ref=pd_sim_351_2?_encoding=UTF8&psc=1&refRID=2B85PVJ9JR002JY9J3XX

This, $5.99 on amazon: https://www.amazon.com/dp/B07RLTF27H

Here is the mobile version of your link

https://www.amazon.com.au/Agile-Project-Management-Scrum-Schwaber/dp/073561993X

There's this, that has a couple 'real world' examples