How to handle sprints when things are blocked on partners (third parties)

[Amina Layco]

Hi,

We fibonacci estimate our tasks, do planning and then we have 2 weeks sprints. It works perfect for us when the tasks we have depend only on us. 

The problem is that we also need things done from partners to implement, and these different partners are unpredictable: they could finish a task in a day or in a week or in a month. These are tasks that our partners need to do (so in theory they shouldn't go in the sprint, right?), but some of our team members have to follow up on these tasks: nag, communicate, ask what the status of the tasks are, push them, etc. Also when they finish the task someone of our team has to test it. How can we track this effort that WE make from our partner's tasks?

What we do for now is create tasks like "Follow up PartnerX and test" and estimate accordingly. Those tasks are going to be blocked until our partners do their part, so they can be blocked for many sprints. Is that okay? Does it make sense to track this tasks if they don't really live in our sprint workflow? Should we be having tasks about following up with partners?

 BTW: we use Jira and some team members don't want to have different boards for this because it would lose visibility.

Any help is appreciated! Thanks.

[Ron Jeffries]

Hi Amina,

I have questions …

On Aug 2, 2017, at 11:33 AM, Amina Layco <amina...@gmail.com> wrote:

The problem is that we also need things done from partners to implement, and these different partners are unpredictable: they could finish a task in a day or in a week or in a month. These are tasks that our partners need to do (so in theory they shouldn't go in the sprint, right?), but some of our team members have to follow up on these tasks: nag, communicate, ask what the status of the tasks are, push them, etc. Also when they finish the task someone of our team has to test it. How can we track this effort that WE make from our partner's tasks?

First, why do you need to follow up and nag and communicate and such? Why aren’t these so-called “partners” pro-actively communicating? Why should your team need to do things to cause these so-called partners to behave professionally?

Second, why are these so-called partners not committing to delivering software by some agreed date?

Third, what if you had automated tests that ran with your own continuous build (you have one, right?) and had your dashboard display all the things these partners are still red on?

Fourth, consider a Big Visible Chart showing WASTED TIME as a huge red swath amid all the good things you’re doing? Put the chart somewhere where important managers see it. When they ask you what all that wasted time is, tell them.

Look at http://ronjeffries.com/xprog/articles/bigvisiblecharts/ for examples.

Ron Jeffries

ronjeffries.com

I have two cats, and a big house full of cat stuff. 

The cats fight and divide up the house, messing up their own lives. 

Nice work cats. 

Meow.

[Derek Davidson]

Hi Amina

Great advice from Ron, as usual. In addition, I often offer the following rule to teams I am working with:

"Never accept a product backlog item into the sprint where a third party dependency exists unless the third party dependency commits to deliver within the sprint"

--

Derek

--

Derek Davidson

Agile Coach & Professional Scrum Trainer

Author of the Agile Annex

Helping large organizations successfully adopt the benefits of scrum

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumalliance+unsubscribe@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at https://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

[Alan Dayley]

Amina,

Isn't great how Scrum has made obvious the difficulty caused by weak connections with partners? Help your leaders see and fix this impediment. Ron has good ideas about making it more obvious.

Alan

[Michael Vizdos]

And.

As others have stated so far... this goes to a good "Definition of Ready" to highlight the impediments to the team meeting a "Definition of Done".... 

Don't pull work into a Sprint until something is "Ready" (which means the dependencies you mention are removed).

It's a problem with or without Scrum.  This just is highlighting it as an impediment that needs to be addressed.

Make sense?

- mike vizdos

  www.michaelvizdos.com

  www.implementingscrum.com

  www.agilementoring.com 

On Wed, Aug 2, 2017 at 2:40 PM Alan Dayley <ada...@gmail.com> wrote:

Amina,

Isn't great how Scrum has made obvious the difficulty caused by weak connections with partners? Help your leaders see and fix this impediment. Ron has good ideas about making it more obvious.

Alan

On Wed, Aug 2, 2017 at 8:33 AM, Amina Layco <amina...@gmail.com> wrote:

Hi,

We fibonacci estimate our tasks, do planning and then we have 2 weeks sprints. It works perfect for us when the tasks we have depend only on us. 

The problem is that we also need things done from partners to implement, and these different partners are unpredictable: they could finish a task in a day or in a week or in a month. These are tasks that our partners need to do (so in theory they shouldn't go in the sprint, right?), but some of our team members have to follow up on these tasks: nag, communicate, ask what the status of the tasks are, push them, etc. Also when they finish the task someone of our team has to test it. How can we track this effort that WE make from our partner's tasks?

What we do for now is create tasks like "Follow up PartnerX and test" and estimate accordingly. Those tasks are going to be blocked until our partners do their part, so they can be blocked for many sprints. Is that okay? Does it make sense to track this tasks if they don't really live in our sprint workflow? Should we be having tasks about following up with partners?

 BTW: we use Jira and some team members don't want to have different boards for this because it would lose visibility.

Any help is appreciated! Thanks.

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.

To post to this group, send email to scruma...@googlegroups.com.
Visit this group at https://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.

To post to this group, send email to scruma...@googlegroups.com.
Visit this group at https://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

--

Thank you.

- mike

  Focus. #deliver
  www.michaelvizdos.com
 

[Pierre Neis | We&Co]

option 1: improve the definition of done according the work stream of the team. « done »  means then before hand over to third party and start measuring cost of delay if necessary.

option 2: an item is blocked because of 3rd party, then create sub-tasks and validate all according to previous comment and transform task into item.

In any cases, try to improve your organisation so that team owns end-to-end development. 

PierreNEIS
Senior Lean Agile Coach | Associate
M: +352 / 661 727 867
UK: +44 / 203 239 52 60
wecompany.me | You can book me

Actually Scrum Coach for Corporate Finance & Treasury @ SAP SE

[Amina Layco]

Hi Ron,

Thank you for the reply. About your 1st and 2nd points, there isn't much we can do about, we tried to make this situation better but we just have to accept different partners work in different time schedules and their own priorities change everyday.

We don't have a continuous build but I didn't understand how you mean it could help? We could put in our sprint board the tasks that our partners are doing. But is it the right thing? It will quite ruin the velocity and predictability of our own sprints.

I quite like the Big Visible Chart idea! So in there we can track all this non development effort that we do when we communicate with partners, right?

Cheers,

Amina.

[Amina Layco]

Hi Derek,

Thanks. Yes, that makes sense. And what about how to track the communication effort? Because this is an ongoing task through all the sprint. So if they have a question, one of the developers have to spend time answering that.

On Wednesday, August 2, 2017 at 6:29:39 PM UTC+1, Derek Davidson wrote:

Hi Amina

Great advice from Ron, as usual. In addition, I often offer the following rule to teams I am working with:

"Never accept a product backlog item into the sprint where a third party dependency exists unless the third party dependency commits to deliver within the sprint"

--

Derek

--

Derek Davidson

Agile Coach & Professional Scrum Trainer

Author of the Agile Annex

Helping large organizations successfully adopt the benefits of scrum

On Wed, Aug 2, 2017 at 4:33 PM, Amina Layco <amina...@gmail.com> wrote:

Hi,

We fibonacci estimate our tasks, do planning and then we have 2 weeks sprints. It works perfect for us when the tasks we have depend only on us. 

The problem is that we also need things done from partners to implement, and these different partners are unpredictable: they could finish a task in a day or in a week or in a month. These are tasks that our partners need to do (so in theory they shouldn't go in the sprint, right?), but some of our team members have to follow up on these tasks: nag, communicate, ask what the status of the tasks are, push them, etc. Also when they finish the task someone of our team has to test it. How can we track this effort that WE make from our partner's tasks?

What we do for now is create tasks like "Follow up PartnerX and test" and estimate accordingly. Those tasks are going to be blocked until our partners do their part, so they can be blocked for many sprints. Is that okay? Does it make sense to track this tasks if they don't really live in our sprint workflow? Should we be having tasks about following up with partners?

 BTW: we use Jira and some team members don't want to have different boards for this because it would lose visibility.

Any help is appreciated! Thanks.

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.

[Howard Sublett]

Rule #1 in this group. 

If Ron Jeffries makes a suggestion for you, take it.   It's a great idea!

Howard Sublett

Cell: 501.622.7929

Sent from my iPhone

[Derek Davidson]

Hello Amina

> And what about how to track the communication effort? ... one of the developers have to spend time answering that.

Two things come to mind:

1. Is there a really compelling reason to track communication effort?

2. Let the team express their feelings on time spent communicating in the retrospective and, if it's an issue, ask them for ideas on how to improve.

One final thought: If you find yourself wholly dependent on third parties, question whether your scrum team is correctly formed. As the scrum guide says: "Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;"

--
Derek

To unsubscribe from this group and stop receiving emails from it, send an email to scrumalliance+unsubscribe@googlegroups.com.

To post to this group, send email to scruma...@googlegroups.com.
Visit this group at https://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

--

Derek Davidson

[Ron Jeffries]

Hi Amina,

On Aug 2, 2017, at 1:25 PM, Amina Layco <amina...@gmail.com> wrote:

Thank you for the reply. About your 1st and 2nd points, there isn't much we can do about, we tried to make this situation better but we just have to accept different partners work in different time schedules and their own priorities change everyday.

Well, OK. I’m not much for accepting things that aren’t good, but everyone gets to decide what hill they’ll die on.

As has been otherwise suggested, I’d say never schedule any of your work until you have whatever these “partners” are supplying.

I’m still not clear on why your team has to chase the other teams.

We don't have a continuous build but I didn't understand how you mean it could help? We could put in our sprint board the tasks that our partners are doing. But is it the right thing? It will quite ruin the velocity and predictability of our own sprints.

Long ago, we had a build board that showed which tests were running and which were not. Our Product Owner was supposed to supply us with valid answers for many of the tests, and they were falling behind. So we had a huge swath of red on our chart that was partly due to things we had wrong, and partly (a lot) due to not having good answers.

So we changed the chart to show red for broken and yellow for unknown data. Suddenly there was this big band of yellow. Our product owner asked us what the yellow was. We said “These are all the tests where YOU don’t know whether the system is right or wrong, because we don’t have the data.” On the spot she called the person responsible for getting the data and put the spurs to her. Soon we had our data.

Same thing with your build (and you should have a continuous build if you want more than a C in the course :). If you communicate with your “partners” (are you sure they wouldn’t better be called “obstacles” or “enemies”?) via tests, then you can show all their tests in some horrible purple color and have the dashboard where management will see it and ask you what’s up. Then you tell them.

I quite like the Big Visible Chart idea! So in there we can track all this non development effort that we do when we communicate with partners, right?

Well you can, and it will at least show how much time is being wasted. A better plan would be to stop wasting the time, by putting responsibility on these not-very-much-like partners. I think I asked why you have to follow up on them. Two part question, really. First, if they’re responsible they should be giving you dates and meeting them, so no one should have to call them and ask them questions. Second, if they must be asked questions, maybe someone else should be doing it, if you’re supposed to be developing software.

Anyway, Scrum is telling you clearly that you have an impediment. Your mission is to work to remove it. Good luck!

Ron Jeffries

ronjeffries.com

They’re not anecdotes, that’s small batch artisanal data. — Sara (@pikelet)

[Michael James]

> On Aug 2, 2017, at 10:33 AM, Amina Layco <amina...@gmail.com> wrote:
>
> we also need things done from partners

I'd like to explore why your team depends on these partners. Is it because of skills (your team doesn't know how to change the other code), or policy (someone will get mad if your team changes the other code)? I'm more impressed when ScrumMasters remove these obstacles rather than accommodate them.

--mj
(Michael)

[George Dinwiddie]

Amina,

You've gotten a variety of good advice. Let me suggest a couple more
ideas that I've seen work well.

1. Prominently mark blocked stories. Make them visible. I'm not sure how
to do this if you're depending on an information refrigerator like Jira.
I like a big wall. I worked with a team where almost every story got
blocked because another team had failed to deliver when they said they
would. No one got mad because the velocity plummeted. It's just the way
it was. And the team spent the time working on deferred technical debt.

2. Try a Portfolio Alignment Wall
(https://www.agilealliance.org/wp-content/uploads/2016/01/PAW_Process_Roles_Rules_Nationwide.pdf).
This helps teams to coordinate their work and communicate when there are
going to be delays.

In any event, one team can't make the entire portfolio of work come
together. Either all the teams work together for that, or someone above
all the teams takes the responsibility. Or both.

- George

> --
> You received this message because you are subscribed to the Google
> Groups "Scrum Alliance - transforming the world of work." group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to scrumallianc...@googlegroups.com

> <mailto:scrumallianc...@googlegroups.com>.

> To post to this group, send email to scruma...@googlegroups.com

> <mailto:scruma...@googlegroups.com>.

> Visit this group at https://groups.google.com/group/scrumalliance.
> For more options, visit https://groups.google.com/d/optout.

--

----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Andy Watkins]

Hi Amina, 

A couple of suggestions, based on my past experience on Jira-based Scrum projects

Create a Jira ticket called "receive <thing> from partner" (you may need several, one for each task the partner has to accomplish). 

Create a jira ticket to test the thing, which depends on the ticket to "receive".

If you set up your Jira board with a "Blocked" column, and mark the "receive" tickets as Blocked, it will be clear where the problem lies. You can't do anything with the tasks from your partner until they're unblocked, so these tasks are not ready for inclusion in a sprint.

Create a Jira ticket called "Communicate with partner" purely to track time for things that needed to be done. This isn't pure Scrum, but it was useful for tracking how long things were taking. Make sure your team are filling this in, so the PO can see how bad it is.

Hope this helps.

Andy

Andy Watkins

an...@wis.co.uk

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

To unsubscribe from this group and stop receiving emails from it, send an email to scrumalliance+unsubscribe@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.

[Amina Layco]

Okay.

From what I can read, the conclusions are:

1- DON'T put things on the sprint that can be blocked by third parties unless there is a committed day of delivery from them

2- Track team member's communication with partners either with a placeholder task in Jira or a physical board on the wall

Thank you everybody for all the responses!

Andy Watkins

an...@wis.co.uk

To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.