What are some social and technical solutions to sharing code and interfaces?

Question

Background:

I am a product manager for a medium size web hosting company and we offer a variety of complementary services besides just webhosting.

Today our company has about a dozen 3-6 developer teams each working on different facets of webhosting (i.e. DNS registration, shared hosting, cloud computing, dedicated servers, resales, etc.).

We've grown very organically and as a result the user interface greatly reflects the organization of our company as opposed to the organization of content which our client would find intuitive.

In addition to this problem, many of the backend systems fall in the domain of each team, but need to be used by other teams as well. For example DNS registration services needs to be used by the shared hosting team on their panel. Another example, web hosting features like one-click web application installers are developed by the shared hosting team, but we also want to make them available to dedicated hosting customers.

FYI, we have a programming environment which is heavily focused on agile methodologies and extreme programming (XP).

Question:

For those of you who have corporate work/programming environments similar to mine, what solutions/advice do you have for making this arrangement work so that we can improve the user experience and coordination and sharing of code, while also allowing the teams to remain independent?

i.e. has anyone here used Scrum of Scrums. If so what advice do you have for implementing it?

Any alternative solutions to a scrum of scrums?

Answer 1

I have met a few CSM's who are successfully running a Scrum of Scrums, but it can be difficult to manage unless you're already experienced with Scrum.

Answer 2

Having each developer assigned continually to the same piece of the system increases the differences across products. Reduce this by moving developers across these teams. It will also reduce information silos and increase their understanding of how the piece they are developing fits in the business. You shouldn't overdo this as well.

Regarding system's integration. These are different services with different needs, which all have their own context. It is ok for these applications to be focused on their own context, since that reduces plenty other problems.

What you want to do is make sure there are clearly defined points of integration between the services. It is about agreeing on how will the systems interact and the contracts of information involved. This should operate at the application level, as opposed to the database level. It is also about operations and information/intelligence on it, not about data. Here is a very nice article about enterprise architecture.

Answer 3

First, you need a version control (I assume you're already using one). Make sure to set the right privileges to each developer so they don't "accidentally" break things. This should give developers from Team A access to Team B's code.

Second, to make sure Team A is not using unusable/incomplete code from Team A, Team A needs to publish a "usable/good" code for other teams to use. This can be accomplished either by branching from that specific "usable/good" revision, or just sending out the "usable/good" revision number.

Lastly, it's all about establishing an honest and open communication between teams. Make sure all interfaces and roles are clearly defined.

Answer 4

Interfaces should be clearly defined before the code is written. An interface definition can be altered later if necessary, but this should only be done with the collaboration of all teams that develop for and use that interface. Having a consistent, well-defined interface helps encapsulate parts of the system, and can make it much easier to re-use common components or libraries. Good encapsulation and modularization are a necessary prerequisite for effective code re-use between independent teams (I'm assuming some sort of version control system is used).

Easy access to up-to-date documentation is a must. For an agile/XP environment, my personal recommendation would be to set up a project wiki to be used for a central documentation hub. As a feature/interface/function is created or modified, part of the development process should be to create or update the documentation for that component. A developer taking half an hour to adequately document something can save a half dozen other developers half an hour each trying to figure it out on their own. Using a wiki for documentation can make it easier to make fast edits, allow multiple editors for a single page, and ensure that everyone is using the most up-to-date documentation (no potentially outdated 'local' copies of documents floating around).

We've grown very organically and as a result the user interface greatly reflects the organization of our company as opposed to the organization of content which our client would find intuitive.

That situation can occur when the interface is not treated as a separate, modular component. An interface should plug into the functionality beneath it but should not necessarily represent the structure of the underlying organization. I often see this sort of thing when an interface is built by 'hacking'; that is, a developer builds a new feature and modifies the UI just enough to support their feature, then the next developer does the same, etc etc until the entire UI has been cobbled together with no overarching design goals or principles. Do not underestimate the importance of the user interface or the difficulty of creating a high-quality, consistent interface. Dedicating an engineer (or small team in the case of a larger project) to design and maintain the user interface can greatly enhance the value of your product from the customer's point of view. Since the customer typically sees the user interface and none of the internal workings, the interface should be more than the product of 1% of the team's labor.

Implementing a "scrum of scrums" structure is fairly easy if you get all of the individual teams on the same track. Each day, each small group/team meets for a brief status report/scrum meeting, after which each small group's designated "leader" meets for another scrum on the next level "up the food chain". Since this can be repeated up numerous levels of hierarchy, it tends to work best when the small group scrums happen first thing in the morning, and each level of scrum has a hard and fast time limit (usually 15 minutes, or 2-3 minutes per person will suffice). The time limits are useful to prevent one team going overtime and delaying their leader from the next level of scrum meeting, etc.

Answer 5

"Any alternative solutions to a scrum of scrums?"

Yes. An architect.

The job of an architect -- in this context -- is not to dictate the architecture.

The job of an architect is to coordinate among the teams. Meet with everyone on a regular basis. Participate in the scrums, help where help is needed.

Most importantly:

• Act as governance over change requests.

• Establish a shared vision among the various teams.

This requires the technical depth to understand everything that's going on, as well as the political skills to be sure everyone is being heard.

Finally, it requires management backing to enforce decisions. If, for example, the consensus among all development teams but one is technology X, and and one team is holding out for technology Y, it may be time for one team to find a new job in a different firm.

Answer 6

• Have the team meet and talk about their work. At least if everyone is aware of who the subject matter experts are they can leverage that experience.
• If you're too large to meet have a company wiki and encourage people to use it to share solutions.

Answer 7

I agree with S. Lott. You need an Information/UX Architect with power. That person should have the respect of developers by having worked on innovative projects before.