3

Where I work, there are two teams of developers.

Team A use Kanban and consider quality non-negotiable. They are responsible for developing the client-facing website, part of which contains an important video/media player as an embedded widget.

Team B use Scrum and consider quality a lot less than team A. Team B are responsible for creating the aforementioned video/media player.

Most of the time, both teams work separate from each other on their projects. Occasionally, team A will integrate a new version of the video/media player, which leads to huge delays dues to bugs in the player (almost always due to no a non-quallity-driven approach). Because team A use Kanban, and therefore have WIP limits, the whack-a-mole bug fixing that takes place on team B blocks their releases.

My question is, are there any known ways that team A could attempt to prevent this in future releases where they know they will hit the same issues?

  • 1
    continuously integrate their both prod and dev branch into your dev branch – Imre L Jan 14 '16 at 10:48
  • Due to team B taking excessive time to play whack-a-mole, it's difficult to continuously integrate their development branch into team A's project. – Dean James Jan 15 '16 at 7:41
2

The fact that Team A uses Kanban and Team B uses Scrum is probably incidental to the situation. Fundamentally, the two teams have a different attitude towards quality of their work and its impact on their customers. Besides impacting Team A's performance, they may also be impacting their external customers, which management may not even be aware of.

The long term solution is to show Team B the impact of their shoddiness. Perhaps the Support organization can show some analysis of support tickets for the company and see if there is indeed impact to customers for Team B's work. Perhaps there is market release data for products that both teams work on to show that Team A's products are getting to market more often, thus positively impacting company revenues. There certainly needs to be some management intervention based on this evidence to motivate Team B to improve.

However, in the short run, some other steps might also work.

One way to do so would of course be for Team A to have a frank conversation with Team B to explain their situation and see if there is anything they can do to help get the video player release on time. If they can somehow get that message across, that would help Team A. They could even enlist an external coach/ trainer to help them with this task.

Second, given Team B's past performance, Team A can forecast when realistically they will actually get a bug-free version of the player, and incorporate that in their own release plans. So, specific tasks and features that integrate with the player can be done earlier in the release cycle, so that integration efforts can begin and all bugs reported by Team A can be fixed by the Team B. Perhaps a couple of cycles of this testing can be pre-planned and incorporated in Team A's release plan. Separately, all other features of Team A's release can continue (the ones that don't depend on the player integration) and finish in parallel to the testing, debugging and the final release of the video-player and its integration to Team A's product. This way, they can continue to make releases as per their plan while incorporating the rework of Team B in their plan. The picture below hopefully helps illustrate my point :)

enter image description here

If needed, the two teams might have to do multiple iterations.

Easier said than done, of course! Clearly, Team B has issues relating to team management, team dynamics, individual motivation, etc. that makes them continue to function the way they do. Unless these are addressed, including perhaps rebuilding the team with some fresh blood and ideas, this will continue to drain company resources, revenue and profits - as also overall employee morale.

HTH. Good luck!

0

Option 1. Team B can try to predict the quality of the new releases based on previous releases. I assume Team A does not improve a lot since it happened on several occasions, so knowing number of bugs of previous releases and the time Team B need to fix them, Team A can commit to later release dates.

Option 2. Team B escalates and if their release is late because of Team A, they go to management and suggests Team A to improve.

Option 3. Team B goes to Team A demos, try things out there and if the product is buggy they don't accept the sprint, hence Team A has to fix the bugs before releasing.

Option 4. Team B delegates developers to Team A to help them to be more quality oriented.

Option 5. Team B could take nightly releases from Team A and do pre-checks on the upcoming versions and give early feedback.

Option 6. Use other player (I know this very unlikely but still an option).

0

This is one of the reasons why ideally agile teams contain all the people necessary to deliver a product. When you have functional rather than feature teams you immediately create dependencies.

The ideal solution would be to create one or more cross-functional teams that deal with end-to-end feature requests.

An alternative solution would be for Team A and Team B to work together more closely. Hopefully some of the quality philosophy would rub off on Team B.

A final option, which is not really in the spirit of agile, would be for Team A to do acceptance testing of a media player release. If the media player component was not of sufficient quality then they would reject the release.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.