Project Management in Practice Agile Agile 101 Introduction to Agile

Transcription

1 101 Introduction to 7-1

2 Introduction Overview Brief History of Methodologies vs. Traditional PM 7-2

3 Introduction 7-3

4 After today s session, you ll walk away with: An understanding of what means in the project management community The differences in between methods and traditional project management methods Some of the most popular methods, with a deeper dive into one of the most popular methods 7-4

5 Introduction Overview 7-5

6 is a Mindset or a Philosophy Under the umbrella, there are numerous Frameworks or Methodologies Sources: scrum.org, wikipedia.com 7-6

7 Ref 1d 7-7

8 advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change. revolves around short, iterative cycles of work. is intended to provide greater flexibility and stability, faster deliver with higher quality, improved development team performance, tighter project control, and faster failure detection. Sources: seguetech.com, wikipedia.com 7-8

9 7-9

10 7-10

11 Analysis Design Develop Test Deploy Analysis Design Develop Test Deploy Analysis Design Develop Test Deploy?!!? 7-11

12 7-12

13 Introduction Overview Brief History of 7-13

14 Incremental development methods can be traced back to Evolutionary project management and adaptive software development emerged in the early 1970s. During the 1990s, a number of lightweight software development methods evolved in reaction to the prevailing heavyweight methods that critics described as heavily regulated, regimented, and micromanaged. These included: From 1991, RAD (Rapid Application Development) From 1994, DSDM (Dynamic Systems Development Method) From 1995, Scrum From 1996, CCM (Crystal Clear Methods) and XP (Extreme Programming) From 1997, FDD (Feature Driven Development) 7-14

15 In February 2001, seventeen software developers met at the Snowbird resort in Utah to discuss lightweight development methods, among others Jeff Sutherland, Ken Schwaber, and Alistair Cockburn. Together the seventeen published the Manifesto for Software Development. Working Software over comprehensive documentation Working software is more useful and welcome than just presenting documents to clients in meetings Customer Collaboration over contract negotiation Requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important Responding to Change over following a plan methods are focused on quick responses to change and continuous development Individuals and Interactions over processes and tools Self-organization and motivation are important, as are interactions like co-location and pair programming 7-15

16 Video Call Phone 7-16

17 2002 Scrum Alliance was created 2004 Kanban was created 2009 Scrum.org was created In 2011 the original Alliance created the Guide to Practices Related disciplines, including project management organizations such as PRINCE2 and PMI (Project Management Institute), and Business Analysis organizations (IIBA) have extended or updated their bodies of knowledge and certifications to embrace working with methods. Source: Wikipedia.org 7-17

18 The Manifesto is based on twelve principles: 1. Customer satisfaction by early and continuous delivery of valuable software 2. Welcome changing requirements, even in late development 3. Working software is delivered frequently (weeks rather than months or years) 4. Close, daily cooperation between business people and developers 5. Projects are built around motivated individuals, who should be trusted 6. Face-to-face conversation is the best form of communication (co-location) 7. Working software is the principal measure of progress 8. Sustainable development, able to maintain a constant pace 9. Continuous attention to technical excellence and good design 10. Simplicity the art of maximizing the amount of work not done is essential 11. Best architectures, requirements, and designs emerge from self-organizing teams 12. Regularly, the team reflects on how to become more effective, and adjusts accordingly Ref Manifesto 7-18

19 Blue line project management Red line Traditional project management 7-19

20 Blue line project management Red line Traditional project management 7-20

21 Introduction Overview Brief History of Methodologies 7-21

22 methodologies were initially created for software development, but some have progressed and can be used for any project type. The different methodologies may be better designed for certain work structures, as they all have different processes that will require different and more / less rules to follow. 7-22

23 Some of the most popular methods: Acceptance Test Driven Development (ATDD) Adaptive Software Development (ASD) Modeling Unified Process (AUP) Crystal Clear Methods Disciplined Delivery (DAD) Dynamic Systems Development Method (DSDM) Extreme Programming (XP) Feature-Driven Development (FDD) Lean Software Development Kanban Personal Software Process (PSP) Rapid Application Development (RAD) Rational Unified Process (RUP) Scrum Scrumban Team Software Process (TSP) Unified Process (UP) Ref Wikipedia.org 7-23

24 Scrum: Scrum is an iterative and incremental agile framework A key principle of Scrum is its recognition that during product development, the customers can change their minds about what they want and need Focus is on maximizing the team's ability to deliver quickly There are three core roles in the Scrum framework and these roles would ideally be co-located Product / Project Owner Scrum Master Development / Scrum Team 7-24

25 Product or Project Owner Represents the product's stakeholders and the voice of the customer Accountable for ensuring that the team delivers value to the business Scrum Master Is accountable for removing impediments to the ability of the team to deliver the product goals and deliverables Is not a traditional team lead or project manager, but acts as a buffer between the team and any distracting influences Will often coach the team, within the Scrum principles, in order to deliver high-quality features for its product Scrum or Development Team The Scrum / Development Team is responsible for delivering potentially shippable increments (PSIs) of product at the end of each Sprint A team is typically made up of 3 9 individuals who do the actual work (analyze, design, develop, test, technical communication, document, etc.). Scrum / Development Teams are cross-functional The Scrum / Development Team in Scrum is self-organizing, even though there may be some interaction with a project management office (PMOs) 7-25

26 Ref 1d 7-26

27 Ref 1d 7-27

28 Ref 1d 7-28

29 Ref 1d 7-29

30 Ref 1d 7-30

31 Ref 1c 7-31

32 Introduction Overview Brief History of Practices vs. Traditional PM 7-32

33 7-33

34 Analysis / Requirement Design Develop Test Deploy 7-34

35 Analysis Design Develop Test Deploy Analysis Design Develop Test Deploy Analysis Design Develop Test Deploy?!!? 7-35

36 Ref 1d 7-36

37 Ref 1d 7-37

38 Ref 1d 7-38

39 Ref 1d 7-39

40 Ref 1d 7-40

41 Pros of methods Working software is delivered much more quickly and successive iterations can be delivered frequently, at a consistent pace. There is closer collaboration between developers and the business. Changes to requirements can be incorporated at any point of the process even late in development. It gives the opportunity for continuous improvement for live systems. It is highly transparent. Ref

42 Cons of methods methodologies (e.g. Scrum, Kanban, etc.) are often more difficult to understand than linear, sequential ones at least initially. Because of the emphasis on working software there can be a perception that documentation can sometimes be neglected. The focus should be on appropriate documentation to the audience that needs it but, if not implemented well, this isn t always the case. When implemented badly can introduce extra inefficiencies in large organizations or can be working against long standing organizational processes. Ref

43 Pros of the Traditional method Potential issues that would have been found during development can be researched and bottomed out during the design phase. If appropriate meaning an alternate solution is selected before any code is written. The development process tends to be better documented since this methodology places greater emphasis on documentation like requirements and design documents. Because the waterfall process is a linear one it is perhaps easier to understand, especially for non-developers or those new to software development, often teams feel more comfortable with this approach. Ref

44 Cons of the Traditional method Often the people we re building software for (the client) don t know exactly what they need up front and don t know what s possible with the technology available. This way of working doesn t handle this problem well. Solution designers often aren t able to foresee problems that will arise out of the implementation of their designs. Changes to requirements (e.g. like those resulting from new technologies, changes in a market or changes to business goals) can t easily be incorporated with the waterfall method and there are often laborious change control procedures to go through when this happens. Ref

45 Homework:

46 THANK YOU! 7-46

47 Sources & References 1. SlideShare.net a. Duong Trong Tan b. Mahfuj, M. Rahman, H. Rahman c. Niranjan Nerlige d. Haresh Karkar e. Nathan Gloyn 2. Dohn Kissinger, PMP, PMI-SP 3. Wikipedia.org 4. manifesto.co.uk 7-47

48 Sources & References Cutter IT Journal, The Viral Growth of Kanban in the Enterprise, 2011, available at from_leankit_kanban.pdf Jeff Patton, Using Kanban Techniques to Control Incremental Development, available at: Henrik Kniberg & Mattias Skarin, Kanban and Scrum - making the most of both, lulu.com, 2010 Eliyahu M. Goldratt, Critical Chain, North River Press, 1997 Richard L. Franks, Do More, Stress Less, Oak Hill Consulting Publishing,

49 Sources & References Kanban and Scrum - making the most of both Kanban kick-start example SlideShare.net the best place to find usable presentation material that others have already spent the time to create 7-49