Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Traditional to Agile Development

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Nächste SlideShare
PMI Conclave - Vijaya Devi
PMI Conclave - Vijaya Devi
Wird geladen in …3
×

Hier ansehen

1 von 53 Anzeige

Traditional to Agile Development

Herunterladen, um offline zu lesen

History of how the traditional software development evolved, how Agile development differes, how can we design self-organizing teams, and a model for facilitative leadership

History of how the traditional software development evolved, how Agile development differes, how can we design self-organizing teams, and a model for facilitative leadership

Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Anzeige

Ähnlich wie Traditional to Agile Development (20)

Aktuellste (20)

Anzeige

Traditional to Agile Development

  1. 1. A Case for the Design of Agile Project Teams PMI Mumbai Chapter Vashi, 21st April 2013 Speaker : S.Vijaya Devi
  2. 2. Contents •Traditional Software Development •Agile Software Development •Design of Agile Project Teams •Facilitative Leadership
  3. 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. 4. Nature of Software • Complexity • Changeability • Invisibility Constraints of the real physical world are not applicable to software
  5. 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. 6. FUNDAMENTAL PRINCIPLES OF ENGINEERING DISCIPLINES
  7. 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. 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. 9. Machine Age • Reductionism • Everything can be explained by analyzing its parts • Analytical Thinking • Cause-and-effect is sufficient to explain everything
  10. 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. 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. 12. Taylorism
  13. 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. 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. 15. Traditional Mindset • Establish stronger procedures and policies • Keep tight control on the process • Correct to the baseline • Be a task master
  16. 16. TRADITIONAL SOFTWARE DEVELOPMENT Characteristics of
  17. 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. 18. Software Development • Highly Variable Requirements • Specialization and diversity of skills • Changing nature of technology • Managing people who deal with such complexity
  19. 19. Software Development Processes • Software Development Life Cycle (SDLC) • Waterfall Model – Requirements Specification – Software Design – Development and Integration – Testing – Implementation – Maintenance
  20. 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. 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. 22. Software Development Processes • Is ‘Defined’ Process Control the right method for software development processes ? • Software Development – Too complex – Unpredictable – Highly creative
  23. 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. 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. 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. 26. NON-TRADITIONAL DEVELOPMENT ENVIRONMENTS
  27. 27. Agile Methodologies • SCRUM • XP • DSDM • Crystal
  28. 28. Agile Methodologies • Empirical Process Control • Thinking and designing organizations as whole ‘systems’
  29. 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. 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. 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. 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. 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. 34. SELF-ORGANIZED TEAMS
  35. 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. 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. 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. 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. 39. Self-organized Teams • 3 conditions to form a self-organized team – Task Differentiation – Boundary Control – Task Control
  40. 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. 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. 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. 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. 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. 45. ROLE OF THE FACILITATIVE LEADER
  46. 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. 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. 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. 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. 50. Group Processes • Problem Solving • Decision Making • Conflict Management • Communication • Boundary Management
  51. 51. Group Structure • Mission and Shared Vision • Group Culture • Goals • Motivating Group Tasks • Clearly Defined Roles • Group Norms • Sufficient Time
  52. 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. 53. THANK YOU

×