(Part 2) Top 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
   

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.

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

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

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.

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.

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.

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

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

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