Connect. Communicate. Collaborate. Securely.

Home » Kerio User Forums » Blog » Shared developers & scrum (Blog)
  •  
Anonymous
Karma:

Kerio’s experience is that it makes sense to share some developers among teams. Let me tell you how we manage one such group, what problems we face and how we learned to overcome them.

One of my teams, the Autobuild, has a wide range of responsibilities (source code management, build infrastructure, build scripts, installers, customizations of our Linux distribution, virtualization, and a few more). If we wanted to have an expert for every area in every product team, it would require several new hires; yet substitutability, expertise sharing and code sharing would still suffer. (“How do you conduct a code review when there’s only one person in the team who barely understands the technology?”)

On the other hand, having these developers outside product teams has drawbacks. (“What do you do when every product team plans to use the shared team exclusively?”) We invented “reversed scrum”: Product owners attend Autobuild team’s planning sessions, bringing their requirements and prioritizing them across the whole company. We have also learned that a shared “resource” cannot be as flexible as a product team, thus we try not to put them onto the critical path – if they (for whatever reason) need to work on someone else’s project for a few days, your project doesn’t halt.

Unfortunately, the shared team’s work for a product lacks an assigned cost, and product managers spend their own team’s time more responsibly than the shared team’s. (“Well, we don’t need it that much, but they could do that for us anyway, let’s ask.”) You know, communism doesn’t work. Though responsible management is a remedy, the ultimate solution is naturally not having the shared team, and a reasonable compromise is having the shared team work more on the shared stuff than on per-product features.

Even worse than struggling with planning, we were not able to foresee all the little yet urgent requests from product developers, which – together with unplanned firefighting of broken builds – consumed almost 50% of the team’s time in some sprints, and still the work on new product features wasn’t smooth and quick enough.

Hence we realized that our product teams had grown enough, so they needed and could afford to have someone on the team who would learn and do the simple but often urgent changes that would otherwise require slow and relatively expensive planning or communication with the Autobuild team. The shared team still develops the shared parts, and also becomes the mentor to the product teams.

Most of the installers have been recently handed over to product teams. As you might guess, the Autobuild team discovered that one of the product developers didn’t ask and made injudicious changes to the installer, so his code had to be heavily reworked; well, that’s life and that’s what code reviews are for. Besides this one-off mistake, we keep the quality, our development is faster, and the Autobuild team now has enough resources to work on company’s source code repository migration to GIT.

To sum up, for Kerio it is reasonable to have a shared team, working for multiple projects, despite the problems it always brings. We adjusted scrum planning, and we watch the problems, and continuously balance what part of work (and workforce) we have on the shared team.

Original article available on our blog.

Previous Topic: 2012: The Year of Alternative IT
Next Topic: Kerio API at the University
Goto Forum:
  


Disclaimer:
Kerio discussion forums are intended for open communication between forum members and may contain information and material posted by members which may be useful in learning about Kerio products. The discussion forums are not intended to provide technical support for any specific product. Any information implied or expressed in the discussion forums is that of the posting member. Kerio is in no way responsible for the information posted in the forums, or its accuracy. Kerio employees may participate in the discussions, but their postings do not represent an offical position of the company on any issues raised or discussed. Kerio reserves the right to monitor and maintain the forums to promote free and accurate exchange of information.

Current Time: Wed Aug 23 14:05:11 CEST 2017

Total time taken to generate the page: 0.00384 seconds
.:: Contact :: Home ::.
Powered by: FUDforum 3.0.4.