Feasibility of Scrum with certain modifications to the philosophy

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.

Answer 2

Regarding your question about teams treading on each other's code - this is what source control is for. Fork for the new stuff, then in the next sprint reintegrate and stabilise.

Regarding q2, scrum is an incremental approach so if the design lends itself to incremental segments of work then of course it's appropriate.

Regarding q3, how could it ever be a bad thing to hire "people that would work well within them and that they would want to work with"?

Answer 3

Team organization and system structure are highly dependent. See Conway's Law

This means that for you to have two separate teams working on two separate code modules (the Library team and the product team) you will need to have a clearly defined communication channel between the teams and thus, the code developed will reflect those channels in the design. Traditionally what this means is you end up defining an API or interface for the library which acts like a contract to which each team can develop. Agile practices normally adopt a more emergent design philosophy so it can be difficult to create an API that makes sense.

The way most agile teams get around this is by time boxing development to manageable increments. So while it might be unrealistic to design the entire API, the product team and library team could probably agree on an API design enough for 2 weeks of work. Write the code, deploy, design for the next iteration, and repeat. This way communication paths between the teams and code modules are established so the two teams can work independently without stepping on one another's toes.

Another option I've seen used recently is to have larger teams managed with a Kanban/Limited WIP process. Having everyone on the same team managed by a Kanban allows for more organic and flexible self-organization which means your system will be able to evolve more easily. By keeping work-in-progress highly visible it increases communication and by limiting work-in-progress you constrain developers from clobbering each other by keeping the system from evolving too far in any one direction. Combined with a solid VCS you should be good to go.

Finally, another option is that you take some time to really think about your architecture before diving into development. Using a software architecture design process such as the Architecture Centric Design Methodology (ACDM) in a limited "spike 0" kind of role could help you resolve many of the issues commonly encountered when allowing emergent design. By the end of the design sprint, you'll be able to lay out a plan that makes much more sense for what you need to do. And remember, just because it's a design phase doesn't mean you don't write code - quite the opposite. ACDM advocates strongly for experimentation.