This document discusses the transition from traditional to agile software development approaches. It outlines some key differences, including that traditional approaches assume linear processes while agile embraces unpredictability. It also discusses how agile uses self-organizing teams and facilitative leadership rather than command-and-control hierarchies. Specifically, it explains that self-organizing teams require differentiated tasks, internal control over boundaries and goals, and how the role of a facilitative leader is to help teams achieve goals by removing obstacles rather than directing work.

1. A Case for the Design of Agile Project
Teams
PMI Mumbai Chapter
Vashi, 21st April 2013
Speaker : S.Vijaya Devi

2. Contents
•Traditional Software Development
•Agile Software Development
•Design of Agile Project Teams
•Facilitative Leadership

3. Software Engineering
• Borrowed from the classical engineering
disciplines
• Application of systematic, , disciplined,
quantifiable approach to the design,
development, operation, and maintenance
of software

4. Nature of Software
• Complexity
• Changeability
• Invisibility
Constraints of the real physical world are
not applicable to software

5. Classical Engineering
• Engineering components exist in the real,
physical world and are constrained by the
laws of that world
• Engineering components interact in
predictable ways
• Classical engineering disciplines have far less
mid-course design changes

6. FUNDAMENTAL PRINCIPLES
OF ENGINEERING
DISCIPLINES

7. Newtonian World Machine
• Clockwork Universe
• The world is a hermetically sealed clock
• The world is a machine
• The world is a closed system

8. Machine Age
• Determinism – everything can be determined
given enough information
• No chance for surprise or creativity
– Everything has a cause
– Linear causality
• Everything is constituted of matter

9. Machine Age
• Reductionism
• Everything can be explained by analyzing its
parts
• Analytical Thinking
• Cause-and-effect is sufficient to explain
everything

10. Scientific Management
• Fredrick Taylor showed the way to
mechanize
– Take the job apart and reduce to
elementary tasks
– Modern factory is a result of the analysis of
work and its mechanization
– Man became the extension of the machine
– Alienation of the worker from his job

11. Taylorism
• ‘Efficiency’ is the mantra
• Specialization of tasks
• Organization as a ‘machine’
• Machine needs to be supervised, man needs
to be supervised
• Separation of planning from operations

12. Taylorism

13. Taylorism
• Men and machine are glued together by
supervisors
• Supervisors control the variations and
‘absorb’ uncertainties
• Further supervisors need supervisors and so
on…
• Work, in order to be mechanized, needs to be
compartmentalized, creating silos

14. Traditional Mindset
• Stability is the norm
• The world is linear and predictable
• It’s controllable
• Minimize Change
• Increase the feeling of security by adding
rigor to the process
• Deliver on the planned results
• Use the plan to drive results
• Aim, aim, fire

15. Traditional Mindset
• Establish stronger procedures and policies
• Keep tight control on the process
• Correct to the baseline
• Be a task master

16. TRADITIONAL SOFTWARE
DEVELOPMENT
Characteristics of

17. Software Laws
• Ziv’s Law – “Specifications will never be fully
understood”
• Humphrey’s Uncertainty Principle – “For a
new software system, the requirements will
not be completely known until after the users
have used it”
• Wegner’s Lemma – “an interactive system
can never be fully specified”

18. Software Development
• Highly Variable Requirements
• Specialization and diversity of skills
• Changing nature of technology
• Managing people who deal with such
complexity

19. Software Development Processes
• Software Development Life Cycle (SDLC)
• Waterfall Model
– Requirements Specification
– Software Design
– Development and Integration
– Testing
– Implementation
– Maintenance

20. Software Development Processes
• The ‘Defined’ Process Control Model
– Every process is well-defined
– For a well-defined set of inputs, there is a
well-defined set of outputs
– Every process is predictable
– Every process is repeatable

21. Defined Process Control
• "A defined process is an amount of tightly coupled
steps where the output from one step is the input
to the next step and where no observation or
evaluation of the output is done to feedback to the
process. A defined process when started will run
to the end without any checkpoint. The output
from a defined process should always be the same
or with little variance given the same input to the
process."

22. Software Development Processes
• Is ‘Defined’ Process Control the right method
for software development processes ?
• Software Development
– Too complex
– Unpredictable
– Highly creative

23. Software Development Processes
• Assumptions
– Extensive upfront planning to deal with
risks
– Problems can be well-defined and an
optimum solution can be devised
– Processes are predictable, repeatable and
optimised
– Processes can be adequately measured and
controlled

24. Management Structure
• Design of an organization is influenced
heavily by the set of assumptions and beliefs
• A mechanistic view of the organization leads
to the belief
– That people are akin to machines
– That people have to be supervised
– They have to be controlled
– They have to be directed
– They have functions, and not purpose

25. Management Structure
• Design of the organizations
– Hierarchical, with a ‘command-and-
control’ style
– Design tuned for high-performance in a
stable environment
– High formalization and standardization
– Specialization of jobs
– Limited Customer involvement

26. NON-TRADITIONAL
DEVELOPMENT ENVIRONMENTS

27. Agile Methodologies
• SCRUM
• XP
• DSDM
• Crystal

28. Agile Methodologies
• Empirical Process Control
• Thinking and designing organizations as
whole ‘systems’

29. Software Development Processes
• “The empirical model of process control
provides and exercises control
through frequent inspection and adaptation for
processes that are imperfectly defined and
generate unpredictable and unrepeatable
outputs”

30. Empirical Process Control
• Expects the ‘unexpected’
• Does not try to define any process completely
• Acknowledges the fact that complex
processes are unpredictable and not
repeatable
• Control is exercised through frequent
inspection and adaptation

31. Sprint in SCRUM
• Iterative or incremental development
• Daily stand-ups
• Retrospective and Reviews
• Processes are improved over a period of time
• Flexibility and adaptation is built-in

32. Management Structure
• Teams are self-organizing
• The Scrum Master role is that of a facilitative
leader
• Less formalization, decentralization and less
supervision
• Cross-functional team with diverse set of
skills
• Collaboration with customer directly

33. Challenges
• Mechanistic to organic design of
organizations
• Moving away from ‘process-centric’ to
‘adaptive’
• Relinquishing ‘command-and-control’
• Setting up self-organized teams
• Redesign of HR processes

34. SELF-ORGANIZED TEAMS

35. Self-organized Teams
• Socio-technical Systems
• Work systems have both technical and social
sub-systems
• Technical subsystem – tools and processes
necessary to create products and services
• Social subsystem – work structure that relates
people to the technical subsystem and to each
other

36. Design Issues
• Unit of Design : Individual vs group
•Technology needs interdependence of tasks
• Locus of Control : external vs internal
– Primary objective is to reduce variation
from goals
•External control (hierarchy, standardization)
•Internal control (self-regulate)
•Control mechanism required to manage
uncertainty

37. Design Issues
• Source of Uncertainties
– High when the task environment is
complex and changing
•Is it possible to predict the rate and nature of
changes coming from the customer ?
– Arising from the technological conversion
of customer requirements to products and
services
•Technology is unknown/new, competent staff
not available

38. Design Issues
• External control in managing the above
uncertainties is ineffective with outside
control
• Regulatory mechanisms are better handled by
those closer to the uncertainties

39. Self-organized Teams
• 3 conditions to form a self-organized team
– Task Differentiation
– Boundary Control
– Task Control

40. Self-organized Teams
• Task Differentiation
– The group task is ‘autonomous’, it is
complete in itself
– The more autonomous the group, the more
differentiated it’s boundary from other
organizational units
– Binds the interdependent tasks into a
common unit
– Contains the variances within the
boundary

41. Self-organized Teams
• Boundary Control
– Transactions with their task environments,
rate and type of inputs and outputs
– A well-defined work area
– Competent workers with a sufficient
variety of skills, which reduces
dependency on external environment
– Group responsibility for boundary control
decisions

42. Self-organized Teams
• Task Control
– To choose appropriate methods and tools
to complete the task
– To make variations on the processes to
match environmental changes
– Influence over task goals so as to allow
modification depending on emergent
situations
– Feedback of measure of group
performance

43. Job Characteristics Model
• Task design is key for employee motivation
• Job characteristics
– Skill variety
– Task identity
– Task significance
– Autonomy
– Feedback
• Psychological conditions of wellbeing

44. Self-organized Teams
• Skill Variety, Task Identity, Task significance
– Personally meaningful work
– Enhance self-regulation
• Skill variety
– Enable responding to changes from
environment
• Task identity
– Grouping interdependent tasks and
controlling variances within the unit
• Task significance
– Satisfies the need to relate individual
contributions to those of other workers

45. ROLE OF THE FACILITATIVE
LEADER

46. Role of the Leader
• Not a manager for the team or the project
• More a facilitator than a leader
• Sometimes called a servant leader
• Sometimes a coordinator

47. Responsibilities
• Help the team achieve business value
• Does not tell the team what to do or how to
do
• Help the group maintain it’s boundaries, by
managing uncertainties
• Removing obstacles to progress
• Manage the process

48. Group Structure
Mission & vision
Group culture
Clear goals
Motivating tasks
Clearly defined roles
Group norms
Sufficient time
Group Context
Mission & vision
Supportive culture
Rewards consistent with objectives
design
Information including feedback
Training & consultation
Technological & material resource
Physical environment
Group Process
Problem solving
Decision making
Conflict management
Communication
Boundary management

49. Facilitative Model
• Determine whether a team is effective
• Identify which factors that contribute to
effectiveness are missing
• Know how to intervene to help a group
become more effective

50. Group Processes
• Problem Solving
• Decision Making
• Conflict Management
• Communication
• Boundary Management

51. Group Structure
• Mission and Shared Vision
• Group Culture
• Goals
• Motivating Group Tasks
• Clearly Defined Roles
• Group Norms
• Sufficient Time

52. Group Context
• Mission and a shared vision
• Supportive Organizational Culture
• Rewards Consistent with Group Objectives
and Design
• Information, including feedback about
Performance
• Training and Consultation
• Technology and Material Resources
• Physical Environment

53. THANK YOU