top of page

Third week - Managing Software Development Teams

It started getting a bit challenging. So, for this week, we had three interesting readings. We have read articles talking about managing large software teams and how the communication take place. To begin with Royce (1970), sharing his experience while managed software development teams that resulted in success of delivering the requirements within time frame and costs. Royce argues that in order to have an effective management on software development groups, companies should follow a guidance of 5 steps. The following figure, summarize his approach.

Royce's Approach (1970)

Figure 1 - Royce's step for effective management software.

In Royce's approach, he suggest the implementation of:

  1. Program Design

  2. Design documented

  3. Do it twice

  4. Plan, control and monitor testing

  5. Involve the customer

Basically, Royce (1970) started with the Waterfall method approach, but analyzing and dividing the categories, he identified that could not have a linear progress for the completion of tasks. Literally, all sections were interacted and tasks would move accordingly to its needs. Therefore, it lead to the complex model above, that illustrate his experience in managing teams and projects.



The second reading is written by Foote and Yoder in 1999 called the Big Ball of Mud. The authors basically defend that how the teams organize to get their task done is more important than design structures to be followed. Due to software complexity, architects would create the big ball of mud structure that does not have a standard to be followed, unregulated growth, etc. However, they defend that such system, for some reason, works perfectly well. They also quoted, "in the end, software architecture is about how we distill experience into wisdom, and disseminate it."(p.33). "The key is to ensure that the system, its programmers, and, indeed the entire organization, learn about the domain, and the architectural opportunities looming within it, as the system grows and matures."(p.34).


The third reading, by Sawyer, S. (2004) "Development Teams" highlights the entanglement of social aspects and technological aspects in software development teams. The author focuses on social perspective and describes the three generic archetypes of software development teams (Figure 2 and 3).


Figure 2 - Three Social Structure Archetypes of Software Development Teams (Source: Sawyer, S., 2004)

Figure 3 - Examples of Archetypes. (Source adapted: Sawyer, S., 2004)


It is important to highlight that a combination of those archetypes is the possible generation of the Hybrid models. The question of which archetype or hybrid blend models is the best is likely to have many answers that varies according to the software to be developed, the team that is going to work on it, the organization structure and culture.


Additionally, the author claims that the "inattention to the social processes and structures often leads to mismatched selections of method and computing technologies."(p. 99).


Last, but not the least we had to do a Guindon design activity that is an adaptation of the Spaghetti Cantilever. Each group had to create a design activity graph (figure 4) and the aim for such exercise was to "To assess the different activities people engage in open ended problem solving design work." (Allen, lecture 3, 2017). Each group reflected on their activity graph and shared their group information among classmates.

Figure 4 - Design Activity Graph (Source: Allen, 2017. URL: https://managingdesignanddevelopment.blogspot.ie/2010/09/guindon-design-activities.html).


This is it for now, let's see which interesting topic will be brought next!


bottom of page