Question

I would prefer if those who answer this question state whether or not they have experience developing in an Agile Environment or if they are speaking from a theoretical standpoint.

Backstory:

Let’s say there is an opportunistic company that develops technologically innovative products (multi-touch interfaces, speech recognition devices, etc, etc) all of which are fundamentally unrelated. However, as one may see, the key advantage of working on products like these are that libraries can be created / extracted from the product and sold to other companies, developers, etc. Thus, working in an incremental fashion is advantageous as it allows the milestones to be separated from the final product.

Question1 : Is this advantageous from a business standpoint? Have any of you encountered the separating of libraries into individual products within your company?

Question2 : If products are indeed created in such an incremental manner, does Scrum seem like a valid methodology to apply?

Let’s assume that this incremental process of creating components to piece together into a final application is set in place. The development team is initially very small, 6 or 7 people. For the fun of it, let’s call this team a Guild. The company is just starting out, and they need to make something profitable. For argument’s sake, let’s say the Guild developed the FaceAPI Library. All of this was done within the Scrum methodology, let’s say in one sprint. Now, the company has enough funding to employ 7 more people. These new 7 people are put into their own Guild, and their skills mirror the skills of the original Guild.

So now, this company has 2 Guilds, and 1 library off which to develop. Let’s say that the one Guild is tasked with creating Product1 using the original library, and the other Guild is tasked with extending the library with more features. These two “sprints” would be carried out concurrently, and at the end the updated library would be merged into the application. As you can see, it is possible that some modifications might need to be made to the library by the team working on Product1, in which case the merge will be non-trivial.

In any case, this is the general idea. The company would have individual Guilds, or teams of people (Question 3: What do you think of this idea? Since teams are smaller, they would want to hire members that have good synergy. Is this likely to increase overall morale and productivity?), which would carry out sprints concurrently. Because of the nature of the service the company offers, the teams would work with more or less the same components, and parts of the applications, however their sprints could be created so that the teams could always carry out work without impediments. Each Guild would be a self-enclosed unit, having testers, designers, and QA’s.

Final Questions:

• As developers or testers, what are
  your opinions on a company that
  functions in this manner? Does it
  foster leadership skills in
  developers? Does it sound appealing?
  Does it sound destined to fail?
• Anyone with knowledge or experience
  with Scrum, does it seem to apply
  naturally in this kind of
  environment?
• Has anyone worked for
  a company that functions similarly to
  the above description? If you don’t
  mind answering, what was it called?
  Was it successful?

Answer 1

To start with, I have been working on 3 more or less Scrum projects so far.

There are a couple of unclear things in your story. What is the company aiming for – developing libraries or final products? To me the two seems fairly conflicting, especially for a small company.

Another thing is, starting development with a library itself without any real users doesn’t sound very agile to me. IMO an agile setup would start the other way around: develop a concrete product first, refactoring the design as dictated by the concrete situation, to possibly arrive to some sort of layered architecture, in which the lower layer(s) could be extracted into a reusable library. Then start developing more concrete products, looking for possibilities to reuse code between the projects, and evolving the design of the common library – again, as dictated by the concrete usage and needs of its clients (the product development teams).

At some point, library development would probably require its own team – in the beginning, it might suffice to have its design and its backlog coordinated between the different teams.