Skip to main content
Project Management

Return to Answer

replaced http://pm.stackexchange.com/ with https://pm.stackexchange.com/
Source Link
Community Bot
Community Bot
  • 1

TL;DR instead of dealing with the bottleneck, focus on its root cause: teams not having integration testing as parts of their "definitions of done".

These teams independently are "agilish" and they do unit testing and functional testing early on in their cycle

First, they should be agile, not "agilish". It will provide lots of value alone, before getting to the integration part. The rest of the answer assumes that you have more or less working agile environment.

These teams [...] can deliver when their changes are in their own application silo without any other impacts.

This implies that they have a stable definition of done and can get stuff to that level. Now, integration part comes in. Going by the lines of the answer to a question with similarities (http://pm.stackexchange.com/a/12792/13461https://pm.stackexchange.com/a/12792/13461), a combined definition of done for the teams involved should cover integration as well. I.e. whatever changes a single team does should leave the whole system functional and should not break anything.

The only recommendation so far is to have teams push their changes into the integration environment as soon as possible.

You don't have any other option to test integration other than actually testing the integration. Delaying that creates an inventory of untested code that is bad.

if there are other recommendations for how to "optimize" in this situation around large integration testing

It doesn't really matter if integration is large or small. If you have changes coming that affect multiple systems, you should be delivering working increments often, and therefore test integration often. This way you will not be accumulating untested parts, and there won't be a bottleneck in the first place.

best practices

The stuff above is not a result of a thought experiment and comes directly from the Scrum Guide (http://www.scrumguides.org/scrum-guide.html) (if you are not using Scrum, it is still a good point):

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.

If the thing that team delivers did not undergo integration testing, it is not done, not useable an cannot be released. Therefore, such sprint did not finish successfully.

TL;DR instead of dealing with the bottleneck, focus on its root cause: teams not having integration testing as parts of their "definitions of done".

These teams independently are "agilish" and they do unit testing and functional testing early on in their cycle

First, they should be agile, not "agilish". It will provide lots of value alone, before getting to the integration part. The rest of the answer assumes that you have more or less working agile environment.

These teams [...] can deliver when their changes are in their own application silo without any other impacts.

This implies that they have a stable definition of done and can get stuff to that level. Now, integration part comes in. Going by the lines of the answer to a question with similarities (http://pm.stackexchange.com/a/12792/13461), a combined definition of done for the teams involved should cover integration as well. I.e. whatever changes a single team does should leave the whole system functional and should not break anything.

The only recommendation so far is to have teams push their changes into the integration environment as soon as possible.

You don't have any other option to test integration other than actually testing the integration. Delaying that creates an inventory of untested code that is bad.

if there are other recommendations for how to "optimize" in this situation around large integration testing

It doesn't really matter if integration is large or small. If you have changes coming that affect multiple systems, you should be delivering working increments often, and therefore test integration often. This way you will not be accumulating untested parts, and there won't be a bottleneck in the first place.

best practices

The stuff above is not a result of a thought experiment and comes directly from the Scrum Guide (http://www.scrumguides.org/scrum-guide.html) (if you are not using Scrum, it is still a good point):

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.

If the thing that team delivers did not undergo integration testing, it is not done, not useable an cannot be released. Therefore, such sprint did not finish successfully.

TL;DR instead of dealing with the bottleneck, focus on its root cause: teams not having integration testing as parts of their "definitions of done".

These teams independently are "agilish" and they do unit testing and functional testing early on in their cycle

First, they should be agile, not "agilish". It will provide lots of value alone, before getting to the integration part. The rest of the answer assumes that you have more or less working agile environment.

These teams [...] can deliver when their changes are in their own application silo without any other impacts.

This implies that they have a stable definition of done and can get stuff to that level. Now, integration part comes in. Going by the lines of the answer to a question with similarities (https://pm.stackexchange.com/a/12792/13461), a combined definition of done for the teams involved should cover integration as well. I.e. whatever changes a single team does should leave the whole system functional and should not break anything.

The only recommendation so far is to have teams push their changes into the integration environment as soon as possible.

You don't have any other option to test integration other than actually testing the integration. Delaying that creates an inventory of untested code that is bad.

if there are other recommendations for how to "optimize" in this situation around large integration testing

It doesn't really matter if integration is large or small. If you have changes coming that affect multiple systems, you should be delivering working increments often, and therefore test integration often. This way you will not be accumulating untested parts, and there won't be a bottleneck in the first place.

best practices

The stuff above is not a result of a thought experiment and comes directly from the Scrum Guide (http://www.scrumguides.org/scrum-guide.html) (if you are not using Scrum, it is still a good point):

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.

If the thing that team delivers did not undergo integration testing, it is not done, not useable an cannot be released. Therefore, such sprint did not finish successfully.

Source Link
Alex Leonov
Alex Leonov
  • 859
  • 6
  • 15

TL;DR instead of dealing with the bottleneck, focus on its root cause: teams not having integration testing as parts of their "definitions of done".

These teams independently are "agilish" and they do unit testing and functional testing early on in their cycle

First, they should be agile, not "agilish". It will provide lots of value alone, before getting to the integration part. The rest of the answer assumes that you have more or less working agile environment.

These teams [...] can deliver when their changes are in their own application silo without any other impacts.

This implies that they have a stable definition of done and can get stuff to that level. Now, integration part comes in. Going by the lines of the answer to a question with similarities (http://pm.stackexchange.com/a/12792/13461), a combined definition of done for the teams involved should cover integration as well. I.e. whatever changes a single team does should leave the whole system functional and should not break anything.

The only recommendation so far is to have teams push their changes into the integration environment as soon as possible.

You don't have any other option to test integration other than actually testing the integration. Delaying that creates an inventory of untested code that is bad.

if there are other recommendations for how to "optimize" in this situation around large integration testing

It doesn't really matter if integration is large or small. If you have changes coming that affect multiple systems, you should be delivering working increments often, and therefore test integration often. This way you will not be accumulating untested parts, and there won't be a bottleneck in the first place.

best practices

The stuff above is not a result of a thought experiment and comes directly from the Scrum Guide (http://www.scrumguides.org/scrum-guide.html) (if you are not using Scrum, it is still a good point):

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.

If the thing that team delivers did not undergo integration testing, it is not done, not useable an cannot be released. Therefore, such sprint did not finish successfully.