Teamwork [Mcconnell] Team Structure [Mcconnell] Configuration Management Principles and Practices – [Kirk Kandt] SW Configuration Management in Agile Methods – [Koskela 2003]

1. ****** Teamwork [Mcconnell] ********************************************************************
Software uses of Teamwork
• Developing and reviewing the project's requirements
• Developing the project's architecture and the design
guidelines that will be used by the whole project
• Defining aspects of the technical environment that will be
used on the project (including the programming languages,
compilers, source-code libraries, code generators, editors,
and version-control tools)
• Developing coding standards that will be used by the
whole project
• Coordinating work on related pieces of a project (including
defining interfaces between subsystems, modules, and
classes)
• Designing difficult parts of the system
• Reviewing individual developers' designs and code
• Debugging difficult parts of the system
• Testing of requirements, design, and code
• Auditing a project's progress
• Maintaining software once it has been built (including
responding to maintenance requests and making
emergency fixes)
Importance to Rapid Development
Small projects can get away with not addressing teamwork issues, but they will benefit from addressing them. Large
projects are group efforts, and characteristics of the groups play an important role in those projects' success, Managers who are
concerned about rapid development would be better off to assign developers based on their abilities to contribute to a cohesive
team first and only then based on their individual capabilities.
Creating a high performance team
Teams need common, shared vision or goals to help them build trust and keep the team focused. Having agreement on
project vision also help to streamline decision making on smaller issues. To have a motivating effect, the vision also needs to be
elevating. The teams needs to be presented with challenging work. As team members work together toward their common vision,
they begin to feel a sense of team identity. For a team to have a results-driven structure, roles must be clear and everyone must
be accountable for their work at all times; team must have an effective communication system; should have means of monitoring
individual performance and providing feedback; and decisions must be based on facts rather than on subjective opinions. Team
members need to be chosen based on who has the competencies that are currently needed. On an effective team, members have
a mix of skills, play different roles and commit to the team. Team members rely on each other’s individual strengths, they look for
ways to become dependent on other team members. Cohesive teams need to stay in communication with each other constantly.
Effective teams have the sense that they are free to do whatever is necessary without interference, having sense of autonomy.
They also need to feel empowered to take whatever actions are needed to succeed. Regarding the team’s size, if the project requires
more than 10 members, if should be broken into multiple teams. For single-project teams, if it can stay together across several
projects, it can expand the size as long as the team shared a deep-rooted culture. Most productive teams are enjoyable, people like
to be productive, they naturally spend more time doing things that they enjoy and what makes a team jell is adopting a group sense
of humor. A cohesive team creates an “us” and the manager is in the sticky position of being not completely “us” and not completely
“them”.
Why teams fail
• Lack of common vision
• Lack of identity
• Lack of recognition
• Productivity roadblocks
• Ineffective communication
• Lack of trust
• Problem personnel
Long term teambuilding
Reasons to keep teams together permanently:
 Higher productivity
 Lower startup costs
 Lower risk of personnel problems
 Less turnover
 Idleness question

2. ****** Team Structure [Mcconnell] *******************************************************************
Consideration in organizing a team is to determine the team’s broad objective. According to Larson & LaFasto: Problem
resolution, Creativity and Tactical execution. The structure that’s more appropriate depends on the team’s objective. The
characteristic that is most important for the kind of team should be emphasized: for problem resolution team, emphasize trust; for
creativity team, emphasize autonomy; and for tactical-execution team, emphasize clarity.
Additional Team-Design features are:
 Clear roles and accountabilities
 Monitoring individual performance and providing
feedback
 Effective communication
 Fact-based decision making
*There’s no such thing as a single best ‘rapid-development team structure’ because the most effective structure depends on the
context.
Team models
Business team: Composed of a tech lead and other equal developers.
Chief-programmer team: is organized around chief programmer who is an expert programmer. The other team members have
other, specialized roles, such as librarian, which support the chief programmer in his primary task of designing and coding the sw.
Skunkworks team: group of talented, creative product developers, working in a facility freed of organization’s normal bureaucratic
restrictions, turns them on the loose to develop and innovate.
Feature team: Small, dynamically formed team that develops a small activity. Multiple minds are always applied to each design
decision and also multiple design options are always evaluated before one is chosen
Search-and-Rescue team: focused on solving a specific problem.
Swat team: each member is highly skilled with a particular tool or practice, trains extensively to be prepared when crisis hits they
can work as a unit.
Professional athletic team: carefully selected people w/very specialized roles
Theater team: “director” assigns roles to others
*Large teams pose special problems of communication and coordination.
Managers and technical leads
Technical lead is responsible for the technical work and for a single team. The manager is responsible for the
nontechnical direction of the team and responsible for 2 or more projects.
******** Configuration Management Principles and Practices – [Kirk Kandt] **************************
A CMS includes a set of policies, practices, and tools that help and organization maintain software configurations. Its
primary purpose is to maintain the integrity of the sw artifacts of an organization. * is the discipline of controlling the
evolution of complex systems
Principles
• Protect critical data and other resources
• Monitor and control sw development procedures and
processes
• Automate processes and procedures when cost effective
• Provide value to customers
• Sw artifacts should have high quality
• Sw systems should be reliable
• Assure that products provide only necessary features, or
those having high value
• Sw systems should be maintainable
• Use critical resources efficiently
• Minimize development effort

3. Practices. They support the previous ten principles.
Management Practices
• Maintain a unique read-only copy of each release
• Control the creation, modification, and deletion of sw
artifacts following a defined procedure
• Create a formal approval process for requesting and
approving changes
• Use change packages
• Use shared build processes and tools
• A version manifest should describe each sw release
• Segregate derived artifacts from source artifacts
Quality Practices
• All artifacts should be under configuration control
• Use a change control board
• Build sw on a regular, preferably daily, basis, followed
by immediate invocations of regression test suites
• Document identified sw defects
• Sw artifacts that comprise a release should adhere to
defined acceptance criteria
• Each sw release should be regression tested before
the test organization receives it
• Apply defect repairs to every applicable release or
ongoing development effort
Protection Practices
• Use a software system to perform configuration
management functions
• Repositories should exist on reliable physical storage
elements
•Configuration management repositories should be
periodically backed-up to non-volatile storage and
purged of redundant or useless information
• Test and confirm the backup process
Tools Practices
• Check code in often
• Configuration management tools should provide
patch utilities
• Do not work outside of managed workspace
• Do not share workspaces
• When developing sw on a branch other than the
primary development branch, regularly synchronize
development with the development branch.
Capabilities. Used to analyze and compare various products
Version Control >> maintain a collection of versioned artifacts.
Configuration Control >> maintain collections of aggregated artifacts that form larger systems and subsystems.
Model Control >> Provide a domain model for sw artifacts.
Build Control >> construct derived artifacts from source artifacts
Change Control > handle all types of change requests and monitor them to closure.
Deployment Control >> automatically deploy sw to customers or notify them when appropriate releases are available
for deployment
Process Control >> automate the workflow of the sw development process and to ensure that practitioners of an
organization follow the desired software process
Security Control >> ensure that users of the configuration management tool perform the operations that they have
been granted and no more
User Interface Control >> provide a Graphical User Interface (GUI) to users that enhance their productivity and overall
experience

4. ****** SW Configuration Management in Agile Methods – [Koskela 2003] *************************
Software configuration management (SCM) is a method of controlling the software development and modifications of
software systems and products during their entire life cycle.
Agile methods focus on generating early releases of
working products and on delivering business value
immediately from the beginning of a project.
SCM differs from general CM: First, software is easier
and faster to change than hardware, and second, SCM
can potentially be more automated.
Configuration identification is a process where a system is divided into uniquely identifiable components, called
configuration items, it consists of selecting the CI’s and recording their functional and physical characteristics and
technical documentation. Examples of CIs are project plan, specifications, design documents, source codes, test plans,
test data, executables, tools and SCM plan.
Per configuration phase, a project baseline is a
document that has been formally reviewed and serves
as basis for further development.
Configuration control > after the configuration items of
the system have been identified, the control of the
changes comes to place. Baseline have important role in
managing change. They can only be changed going
through formal change control procedures as the ones
in the following image. A change request can results
from new features or enhancements.
Configuration status accounting consists of recording and reporting the information needed to manage a configuration
effectively, including a listing of approved configuration identification, the status of proposed changes to the
configuration and implementation status of approved changes.
The purpose of Configuration audits is to ensure that the software product has been built according to specified
requirements, to determine whether all the items identified as a part of CI are present in the product baseline, and
whether defined SCM activities are being properly applied and controlled. A representative from management, the QA
department, or the customer usually performs such audits.

5. The main purpose of the SCM plan is to answer questions as:
who is going to do that, when, where, and how. It serves as a
guideline
Automating manual SCM tasks provides more time to do the
actual development work, leading to improved speed and
productivity.
SCM common tools: Version Control (manage different
versions of congifuration objects that are created during the
sw eng process); Workspace management (prevent users
from interfering with one another’s work); Concurrency
control (files are not locked when checking them out, and
there may be simultaneous modifications to the same files by
multiple users, a locking mechanism comes into use); System
building (combine needed file versions and compile them to
create the app); Press control and support (mechanism to help
reality conform to the model).

6. In agile methods, working software is delivered early
and often. It is valued more than comprehensive
documentation, and therefore documentation can be
added later when there is time.
1. Adaptive Software Development
Offers an agile and adaptive approach to high-speed and high-change software projects.
It encourages incremental, iterative development, with constant prototyping. Lifecycle used is a dynamic speculate-
collaborate-learn lifecycle. Disadvantage > ASDs practices are difficult to identify because of continuous adaptation.
2. Agile Modeling
Practice-based methodology for effective modeling and documentation of software-based systems. It is not a complete
software process, the focus is primarily on effective modeling and documentation.
3. Crystal Family Methodologies
Focuses on individuals’ talents and emphasizes that every team should utilize a process uniquely tailored to itself.
Process and tools are secondary. Based on 2 rules: incremental development and self-adaptation.
4. Dynamic Systems Development Method
It is a framework of controls supplemented by guidance on how to apply those controls. Provides a user-centred,
iterative and incremental way of developing applications systems that serves the needs of the business.
5. Extreme Programming
For teams developing software subject to rapidly changing requirements. It is characterized by short development
cycles, incremental planning, continuous feedback, reliance on communication, and evolutionary design.
6. Feature Driven Development
Focused on delivering frequent, tangible, and working results. Doesn’t cover the entire sw dev process, it rather focuses
on the design and building phases.
7. Internet-Speed Development
Focused on moving the product quickly to market. The quality depends on how important it is to customers and how
good the devs are.

7. 8. Pragmatic Programming
Set of programming best practices. It does not include process, phases, distinct roles or work products, It contains tips
that cover most programming practicalities.
9. Scrum
Management and control process that focuses on building software that meets business needs. Teams are fully
autonomous and guided by their knowledge and experience, rather than formerly defined project plans. Leaves the
power of decision to the devs.