Traditional to Agile Development
1 like1,179 views
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.
Traditional to Agile Development
- 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
- 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
- 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
- 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
- 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