A Case for the Design of Agile Project

Teams

PMI Mumbai Chapter

Vashi, 21st April 2013

Speaker : S.Vijaya Devi

Contents

• Traditional Software Development

• Agile Software Development

• Design of Agile Project Teams

• Facilitative Leadership

Software Engineering

• Borrowed from the classical engineering disciplines

• Application of systematic, , disciplined, quantifiable approach to the design, development, operation, and maintenance of software

Nature of Software

• Complexity

• Changeability

• Invisibility

Constraints of the real physical world are not applicable to software

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

FUNDAMENTAL PRINCIPLES OF ENGINEERING DISCIPLINES

Newtonian World Machine

• Clockwork Universe

• The world is a hermetically sealed clock

• The world is a machine

• The world is a closed system

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

Machine Age

• Reductionism

• Everything can be explained by analyzing its parts

• Analytical Thinking

• Cause-and-effect is sufficient to explain everything

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

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

Taylorism

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

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

Traditional Mindset

• Establish stronger procedures and policies

• Keep tight control on the process

• Correct to the baseline

• Be a task master

TRADITIONAL SOFTWARE DEVELOPMENT

Characteristics of

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”

Software Development

• Highly Variable Requirements

• Specialization and diversity of skills

• Changing nature of technology

• Managing people who deal with such complexity

Software Development Processes

• Software Development Life Cycle (SDLC)

• Waterfall Model

– Requirements Specification

– Software Design

– Development and Integration

– Testing

– Implementation

– Maintenance

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

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."

Software Development Processes

• Is ‘Defined’ Process Control the right method for software development processes ?

• Software Development

– Too complex

– Unpredictable

– Highly creative

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

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

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

NON-TRADITIONAL

DEVELOPMENT ENVIRONMENTS

Agile Methodologies

• SCRUM

• XP

• DSDM

• Crystal

Agile Methodologies

• Empirical Process Control

• Thinking and designing organizations as whole ‘systems’

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”

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

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

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

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

SELF-ORGANIZED TEAMS

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

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

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

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

Self-organized Teams

• 3 conditions to form a self-organized team

– Task Differentiation

– Boundary Control

– Task Control

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

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

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

Job Characteristics Model

• Task design is key for employee motivation

• Job characteristics

– Skill variety

– Task identity

– Task significance

– Autonomy

– Feedback

• Psychological conditions of wellbeing

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

ROLE OF THE FACILITATIVE

LEADER

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

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

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

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

Group Processes

• Problem Solving

• Decision Making

• Conflict Management

• Communication

• Boundary Management

Group Structure

• Mission and Shared Vision

• Group Culture

• Goals

• Motivating Group Tasks

• Clearly Defined Roles

• Group Norms

• Sufficient Time

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

THANK YOU