AKF Partners

Abbott, Keeven & Fisher PartnersPartners In Hyper Growth

Dealing with Shared Services

In our latest Newsletter, we wrote about the importance of aligning your agile teams to the architecture of the system and the trend we are seeing as our clients move towards PODS. We believe and teach that designing your architecture is only the first step in building an organization that can scale in support of your product. Remember, agile autonomous teams are able to act more efficiently which results in a speedier TTM. Ideally, they should almost be able to behave like mini-startups.

Aligning teams to swim lanes is pretty straightforward but what do you do with a team that’s central to multiple services?

We often see clients who have this challenge. They have a shared service or feature that the other clearly split autonomous teams depend on. For example, there are several sites that bring consumers together with businesses in their local area. These sites often have categories or verticals that need search functionality. Asking each team to design its own search functionality would be wasteful as you would end up with engineers designing redundant functionality which would exponentially cost more to operate. It is absolutely feasible to create a team that would focus on search and be used by other teams in this situation. We do recommend that you minimize the existence of these types of teams when possible, as there is always risk that they could slow down TTM.

Great! All of the other teams are going to bombard the shared service team with new development requests. So what do you do to mitigate the risk of over allocating your engineers with such a team?

This risk is real as the other teams will make requests for enhancements or functionality to support their services and they will want it quickly. To mitigate this risk we suggest thinking of the team almost like you would an open source project. That doesn’t mean you simply open up the search code base to all of your engineers and let them have at it. Rather, it means you put mechanisms in place to help control the quality and design for your business. An open source project often has its own repo and typically only allows trusted developers to commit. In our search example, you could designate a couple trusted and experienced engineers in the other PODS that can code and commit to the search repo. Engineers on the search team can be focused on making sure new functionality aligns with architectural and design principles that your company has established. This approach should help to mitigate the potential bottleneck such a team could create.

OK, now that you have spread out the development of search, who really owns it?

Remember, ownership by many is ownership by none. In our example, the search team ultimately owns the search feature and code base. As other developers commit new code to the repo, the search team should conduct code, design, and architectural reviews. Just as the other PODS will deploy new features to production, the search team will also own deployment of search. Overall, all of your teams should have objectives that align with a few key business success metrics.

Remember, whatever mechanisms you put in place, your shared service or tools team should be a gas pedal and not a break for TTM. Good luck scaling your architecture and your organization. We would love to hear about some of the experiences from those of you that have tried this or other approaches.

Comments RSS TrackBack 6 comments

  • carnosine eye drops

    in January 11th, 2013 @ 12:48

    If the future work introduces new technologies or significantly new software functionality, you may want to create a new team project. New technologies or functionality may require very different work flows, testing, build scripts, and more that could, in turn, require significant modifications to the current process template or process guidance.

  • longchamp outlet

    in January 11th, 2013 @ 18:56

    this is extremely interesting. thanks towards the. we have to have more sites similar to this. i applaud you on the great content material and excellent topic selections.

  • Louise

    in January 12th, 2013 @ 00:27

    Excellent read, I just passed this onto a friend who was doing some research on that. And he just bought me lunch as I found it for him smile Thus let me rephrase that: Thanks for lunch! “Any man would be forsworn to gain a kingdom.”

  • Amedar

    in January 12th, 2013 @ 02:12

    I like what you guys are up also. Such intelligent work and reporting! Carry on the excellent works guys Iˇ¦ve incorporated you guys to my blogroll. I think it will improve the value of my site :)

  • Tracey R. Stokes

    in January 15th, 2013 @ 19:44

    Development progress is influenced by the size of the development team and the level of experience amongst them. As an estimate of the effort required to implement the Windows API, there are 1000 or so developers who worked on Windows 7 alone, organized into 25 teams, with each team averaging 40 developers.

  • Organizing platform development – Jay Nathan

    in January 28th, 2013 @ 22:44

    […] Dealing with shared services (AKF Partners blog) strikes a chord for a platform product manager. I can attest to the issues that arise with shared platform teams: overloaded backlogs, undecipherable priorities, increased time to market, loss of ability to drive innovation. […]