10

My current scrum master is a true believer who is not willing to budge on the official forms of scrum. I don't want this to sound ranty, I am really asking about the orthodox solution to this issue because I have been successful resolving issues with him in the past by recasting things in official terms.

The current example of a recurrent issue we have is that there are some ordering dependencies between some of our stories. (In particular, part of the development uses a third party program which we only have a single seat licence for.) There are some necessary setup tasks that are associated with this that have been gathered into a "Setup Story" and then we have 6 tasks that can follow in any order.

The issue is that for the current sprint we pulled in the Setup Story and one of the follow on stories, at which point I said that we cannot take any more stories in this group, even though our sprint is less than half-full. There are unrelated stories on the backlog that were prioritized lower than this group that I suggest we could bring into the sprint. However, these were all prioritized below the stories in this group. At this point the scrum master stated that we should swarm the "Setup Task" and get it done faster, this is a conflict we have had before and he has dug his heels in.

So, for the first half of this sprint two developers and a test resource are watching me work through the external vendor's configuration website, downloading resources, and shuffling certs around. All the while I know that we have a release coming up in three sprints and we could get almost the whole backlog the PO would like done, but we won't because no work is being done on those tasks while everyone sits watching (er, swarms) the setup task for the highest priority story.

My scrum master says that our only concern is completing the stories we accepted for the sprint. Which I understand, but I feel like we are failing the larger organization by not communicating the "bad bin packing" that the prioritization we received from the product owner is causing.

So, how officially are issues of dependencies between stories and inherently serial stories handled by the methodology?

Ukko
  • 203
  • 1
  • 6
  • This third-party licensing limitation is a fact of life and should be used as the reason to reprioritize stories and cancel this sprint and start a new one. As much as everyone may want a particular feature/story done first, it's just not going to happen and it makes no sense for everything to wait. Swarming is one solution that a Scrum Master should suggest, but the team should decide whether or not to do it. I don't think there is anything in the laws of Scrum that would prevent this. – JeffO Jun 14 '16 at 17:14
  • @JeffO We tried to push back a little and basically got a lecture about ignoring the product owner's wishes. There was some talk about using Scrumban at some point in the past and my scrum master was very opposed to that because the PO did not have control. It is part of our particular dysfunction that pointing out that swarming is not appropriate in this situation is answered by swarming even more people. – Ukko Jun 14 '16 at 19:57
  • Why isn't the tester working on their tests and/or test plan? Testing is one activity that should be started well before the code is ready. – Bryan Oakley Jun 14 '16 at 20:20
  • @BryanOakley The answer my scrum master gave me was because they might have a good idea and cross training. Personally, I see it as a waste, my scrum master feels like we should avoid skill silos. My thought was we are experts in our areas, but he says the goal is for us to be able to jump in and help each other. – Ukko Jun 14 '16 at 20:39
  • 1
    @Ukko: that's actually an OK answer. The main goal is to make sure they aren't literally just doing nothing. As long as they are part of the process from the beginning of the sprint to the end, that's all that is important. Too often testing is left to the end of the sprint. – Bryan Oakley Jun 14 '16 at 21:05
  • @Ukko Cross-training is very different from swarming - which is your case? If you feel that the backlog stories are more important than the cross-training (and I'm not weighing in on whether or not they are), you can try phrasing your position as: since cross-training is going on, there should be a story for the cross-training. Now the discussion becomes, should the backlog stories be prioritized higher or lower than the cross-training stories? It seems that the story priorities are determined by your PO, so it becomes your PO's decision, not your scrum master's. – dj18 Jun 14 '16 at 22:06
  • (And if the PO agrees with your scrum master that the cross-training should go on, then there's not much to argue with there.) – dj18 Jun 14 '16 at 22:06
  • I thought the scrum master didn't have any actual authority, so it seems the team is ultimately in charge of how they organize, which includes whether you swarm or not. – Andy Jun 15 '16 at 00:33
  • @dj18 I feel like cross training in this organization is more of an excuse for parking bodies. Basically, you have no work so go sit in Bob's cube and watch him send email to the external vendors. I feel like cross training should have at least a little pedagogical consideration put into it. – Ukko Jun 15 '16 at 14:43
  • @Andy I came from a very comfortable Scrum environment to this place about 2 years ago, I never would have had these issues at the old place. The funny thing is that like a fish doesn't notice the water I didn't notice how good my previous place was. My present job is very "enterprise" in the pejorative sense and they only adopted Agile about a year before I got here. This scrum master was one of the guys who set that up. As a result all of my coworkers follow his lead, you are right he should not have the power he has, but he adjudicates what is "right" and the team does what he says. – Ukko Jun 15 '16 at 14:50
  • Did the SM suggest revising with the PO to see if this new information might change their mind? – JeffO Jun 16 '16 at 21:12
  • In this case it might be a good alternative to review why the dependency is there at the first place. If there is an external party involved you might want to create a task to build a mock service so you can work (and maybe test) the feature. That way you can work again in parallel and as an added advantage the implementation becomes way less hard-connected to the supplier. – Luc Franken Jun 21 '16 at 10:47
  • That is not [Scrum](http://scrumguides.org/) and your so-called Scrum Master needs properly educated.. – Alan Larimer Mar 19 '18 at 22:21

4 Answers4

7

So, how officially are issues of dependencies between stories and inherently serial stories handled by the methodology?

As with anything else in Agile: Individuals and interactions over processes and tools

If your process isn't serving you, then you mold it into something useful. For this, I would pull in lower priority stories (or some technical debt/personal growth that maybe isn't visible in the backlog) until the pre-requisite is cleared. Assuming of course that you've done your due diligence and it really is a hard and fast pre-requisite. For a lot of things, interfaces and mocks can unblock work until the real thing is ready.

Telastyn
  • 108,850
  • 29
  • 239
  • 365
  • I will totally point out _Individuals and interactions over processes and tools_. I am totally in favor of pulling in work, but that is very frowned on, again because we are going against the PO's priorities. The funny thing is that seems to be a theme that is coming up as I describe this. – Ukko Jun 14 '16 at 20:11
  • 2
    @Ukko - priorities are priorities, not a queue. – Telastyn Jun 14 '16 at 20:13
  • 1
    @Ukko: The official Scrum way to deal with that problem is to talk with the PO if they are willing to re-prioritize some work to get the complete backlog done sooner. I still have to meet a PO who isn't willing to work with the team in such a way. – Bart van Ingen Schenau Jun 15 '16 at 06:52
  • @BartvanIngenSchenau mentioning the PO rings a bell. That is one thing that is not well defined here. We don't have a good PO role in the organization, there is a group of BAs that play the role of POs but they are not the real POs. In this case the BA is getting lots of pressure from management on this specific functionality, and she was kind of afraid to have us touch a "low priority" story. – Ukko Jun 15 '16 at 15:16
3

One of the features of kanban, which I believe bleeds over into scrum, is that the process as a whole optimizes for the team, not the individual. In other words, it's no sin if someone on the team is idle for part of the sprint.

If the team as a whole chooses X story points, it really doesn't matter (to the stakeholders) whether one person did all the work or if the work was equally divided. So, if the product owner is happy with the number of points that is brought into a sprint (and this is the product owner's call, not the scrum master!) then that is all that matters.

Of course, that being said, if some team members are not directly involved in the first story, they can be busy writing tests, or doing whatever they can on the other stories.

As a final note, the scrum master has little business "digging in his heels". The scrum master should be working for you to remove barriers to productivity, not set barriers up. If the team as a whole feels they can pull in another lower priority story, that is a decision for the team to make; the scrum master has no final say in the matter.

An exception can be made if the team is young and still learning scrum, but if the team is mature, the whole point of scrum is to empower the team rather than the managers.

Bryan Oakley
  • 25,192
  • 5
  • 64
  • 89
1

The way I see this, you've got two different issues:

  1. How to optimize your team's productivity.
  2. How to order the product and sprint backlogs based on dependencies.

For your team's productivity, I can sympathize with your Scrum Master: I've found, due to human nature, that most people want to keep everyone busy, rather than optimizing the entire team. Being busy does not equal productivity. Idling may be the best thing for a team member to do at a given time.

On the specific matter of the setup task: this sounds like something that should be automated. Given your write-up, if I were working with your team, I'd want to spend some time figuring out what is going on with this setup process that is both time-consuming and blocking, since it sounds like a prime candidate for improving the team's effectiveness.

I would also hope, at a minimum, that you are not the only person on the team who can do this. If you have a day off, I would hope the team has other people who can handle this bottleneck process. Swarming might be a chance to ensure that multiple people learn how to do this.

Assuming that you have an unavoidable dependency between Product Backlog Items (PBI), I would consider all dependent PBIs as blocked until the the blocking dependency is addressed. In general, this means leaving the blocked PBIs out of a Sprint. Since you have control over the blocking dependency, I can see bringing the dependent PBIs into the sprint, but that seems like a risky move. In Sprint Planning, I would generally only expect to consider PBIs that are not blocked.

Bottom line, though, is to find what works best for delivering valuable, tested, working software as effectively as possible.

Dane
  • 111
  • 2
0

The number 1 rule to building your sprint backlog (adding your product backlog items, or PBIs) should be to follow the basic INVEST principle:

  1. Independent: The PBI should be self-contained, in a way that there is no inherent dependency on another PBI.
  2. Negotiable: PBIs, up until they are part of an iteration, can always be changed and rewritten.
  3. Valuable: A PBI must deliver value to the stakeholders.
  4. Estimable: You must always be able to estimate the size of a PBI.
  5. Small: PBIs should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
  6. Testable: The PBI or its related description must provide the necessary information to make test development possible

It seems as though your Scrum Master is forcing the team to break the first rule, all stories in a sprint should be independent - what do you do if you are blocked on that one story that you need to complete to get any other stories closed? You will likely fail the sprint in this case.

I do agree that swarming/pair programming is a good way to collaborate and share knowledge in the team - but if there is no need to swarm on something like this, then I would stick to your guns and quote INVEST :)

Copied from Wikipedia: https://en.wikipedia.org/wiki/INVEST_(mnemonic)

skir2000
  • 21
  • 3