Being Agile in project management


Published on

A concise overview of Agile in Project Management.

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Being Agile in project management

  1. 1. Presentation Written by: Chris Mitchell BEING AGILE IN PROJECT MANAGEMENT
  2. 2. CONTENTS Contents Slide What is Agile Project Management 4 A Brief History of Agile 6 The Agile Manifesto 9 Agile software development diagram Over view 11 A Creative Approach To Project Management (Ron Montgomery) 12 A high level over view of an Agile Scrum project 15 Agile SCRUM Project Processes (Release planning, sprints, user stories, estimation, burn down chart) 16 Agile Scrum Project lifecycle diagram 33 The Success of the FBI Sentinel Project 34 References 35 Resources and Links 36 2
  3. 3. 3
  4. 4. WHAT IS AGILE IN PROJECT MANAGEMENT? Agile is an adaptive, flexible, iterative and customer orientated approach to project management. It promotes customer, user and developer close cooperation in delivering project objectives. It prioritises adapting to change rather then extensive rigid planning. 4 There are different styles of Agile that have been applied to Project Management. Scrum and Kanban are two of the most well known and widely used.
  5. 5. 5 Wikipedia - “Agile management or Agile Project Management is an iterative method of determining requirements for engineering and information technology development projects in a highly flexible and interactive manner. It requires empowered individuals from the relevant business, with supplier and customer input.”
  6. 6. A BRIEF HISTORY OF AGILE Agile management origins were in part first developed by William Edwards Deming in his work helping to rebuild Japan after the second world war using an continuous improvement approach. And also from software development, where iterative software development processes have been noted to have first started in the 1950s(1). A flexible and adaptive software development process was developed by the New York Telephone Companies Systems Development Centre, under the direction of Dan Gielan. (2). 6
  7. 7. 7 What has become termed lightweight Agile software development methods evolved in the mid-1990s as a reaction against heavyweight waterfall methods. These waterfall methods are characterized by critics as a heavily regimented, overly documented waterfall model approach to software development.[4] A BRIEF HISTORY OF AGILE Tom Gilb in the 1970s published concepts of Evolutionary Project Management (EVO). This developed into Competitive Engineering.(3) This is an Agile approach to project management.
  8. 8. A BRIEF HISTORY OF AGILE • Early implementations of Agile methods include Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (DSDM) (1995). • These are now typically referred to as agile methodologies, after the Agile Manifesto published in 2001.[5] 8
  9. 9. THE AGILE MANIFESTO The need for an alternative to documentation driven, heavyweight software development processes that are familiar in waterfall and traditional management processes. Gave birth to what has become known as Agile software development and also Agile Project management. This reached a central moment in 2001 with the creation of the Agile Manifesto. It was founded by a group of software developers who met in Utah to discuss light weight software development processes. 9
  10. 10. THE AGILE MANIFESTO The Four Key Principles: Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. 10
  11. 11. AGILE SOFTWARE DEVELOPMENT DIAGRAM OVER VIEW Although Agile Project Management came out of software development processes and is typically used in this field. Its application can be applied to many types of project. It can be used in various product development, design, government and many other projects and areas. 11
  12. 12. Ron Montgomery A Creative Approach To Project Management (The following text in light yellow was written by Ron Montgomery. Please see slide resources and links for further info) Agile Methodology was born as a lightweight framework for managing software development. It emphasizes business-driven prioritization, responding to change, self- organizing teams, face-to-face communications and quick delivery cycles. It de-emphasizes sequential processes and detailed project artefacts such as specification documents. Since it’s inception, the benefits of the concept have been spread to other areas of business. Today you will often hear the word agile in association with: • Extreme Programming (XP) – System engineering practices. • Scrum – Project management practices. • Lean – Management practices adapted from lean manufacturing. Ron Montgomery 12
  13. 13. The agile movement had been in progress for many years and reached a pivotal point in February 2001 when a group of software development experts met in Utah to ski, socialize, and discuss how to improve software development. The result was the “agile manifesto and principles", which are listed below and also posted at www.Agilemanifesto.Org. Agile Values: “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more. Ron Montgomery 13
  14. 14. Waterfall Agile “Plan the work and work the plan” Plan, work and repeat Plan for activities & tasks Plan for functionality Learn and document everything at the outset of the project Respond to new information during the project Resist changes to scope Welcome changes in scope All scope items must be delivered Functionality will be re-prioritized frequently by the business, and some functionality may never be developed Projects are organized like relay races, with scheduled handoffs between groups Projects are similar to scrums in rugby, as all team members work to move the ball down the field QA is performed at the end of the project or product that is delivered QA is performed continuously Agile is a significant departure from the classical “waterfall” management approach as summarized below: Ron Montgomery 14
  15. 15. A HIGH LEVEL OVER VIEW OF AN AGILE SCRUM PROJECT • The following is a high level overview of how a project may be run using Agile Scrum framework. Scrum is the most commonly used form of Agile project management. • It is important to bear in mind that there are no best practices with Agile. What is most important is adapting an approach that best serves the customer and the team. 15
  16. 16. AGILE SCRUM PROJECT PROCESSES The following points explained further in the next slides are elements that go towards making an Agile Scrum project: • Vision (or Business Case). • Product backlog. • User stories – features and tasks. • Planning poker, story points and estimation. • Sprint planning. • Release planning / Backlogs / Sprints. • Burn down chart. • Scrum / Stand up meeting. • Retrospective. 16
  17. 17. AGILE SCRUM PROJECT PROCESSES 17 The details given below are high level and are not a detailed description of an Agile Scrum project. For further understanding and more in depth explanation please either refer to the web, training, reading and Agile people. The term sprint is specifically used in Scrum. Sprint and iteration mean the same thing in Agile. A sprint is basically a set piece of work consisting of several user stories that is completed in a set time. The sprint is then often repeated.
  18. 18. VISION OR BUSINESS CASE • The Vision or business case: If starting a project from scratch. It will usually be the case that it requires justification. A business case will be created to justify the project/product and its benefits. • If Agile is adapted to a project already in motion, then a new business case would unlikely to be required, unless requested. 18
  19. 19. VISION OR BUSINESS CASE • It has been noted that detailed business cases may not be beneficial to a project. They can be overly documented with various estimations and details that are side lined, not correct or can quickly change. And most of all don’t even get read. • Although business cases (apart from detailed financial information) could be created on just one page. • An Agile project vision should inspire people. 19
  20. 20. AGILE PLANNING BOARD • User stories and tasks are written on cards or sticky notes and stuck onto a board. Or logged in a online Agile software tool such as ‘Jira.’ • At the start of a project or piece of work, all the things that are wanted (User Stories) are listed down and put in a product backlog. This is like a wish list of everything the product should have. PRODUCT BACKLOG 20
  21. 21. PRODUCT BACKLOG • The product back log can also be seen or used as the road map for the product or project. A roadmap is simply an overview of where ideally the project or projects will lead. 21
  22. 22. USER STORIES – FEATURES AND TASKS • User Stories: Agile is a customer orientated approach to project management. So a piece of work that needs to be done is often defined as a user story. This is thinking from the customers perspective. • For example in website development, a user story maybe – “I want to be able to leave feedback in a comments section for each article written.” This is a defined user story and is work to be implemented. • User stories can be written down and collected on sticky notes or cards. 22
  23. 23. USER STORIES – FEATURES AND TASKS • Features: Sometimes user stories and features are given the same definition and used in the same way. Although a feature can be regarded as something different. A feature is a basically an over arching part of a product or service. Or looking at it in another way, it could be described as a detailed experience of how the customer will use all or part of a product or service. • Tasks are set things to do with a User Story. E.g. Create a logo. 23
  24. 24. PLANNING POKER, STORY POINTS AND ESTIMATION • This is a way of estimating how difficult or how long it may take to complete a task / user story • In a team planning session a level of difficulty is set - E.g. 1,2,3,5,8 Etc… 1 being easy and higher figures being difficult. Each team member is asked to estimate how difficult a user story or task(s) may be, by applying a number. This is put on a card or a pre made card is selected. • Card selection is initially done in secret so there is no persuasion or influence from other team members. Planning Poker: 24
  25. 25. • Each team member then shows the number they picked. Then with all the numbers shown a figure is agree upon for the task – (this will be the user story or task story points). • These figures can represent hours. However many people do not like applying time to these figures as time estimates are nearly always out and instead the figures can represent difficulty levels. PLANNING POKER AND STORY POINTS 25
  26. 26. PLANNING POKER AND STORY POINTS 26 • Planning poker is done after tasks and user stories have been created. It creates the estimate for how long or how difficult a task or user story may be. • The collection of these estimates for a given sprint will allow for an estimate of how long the sprint may take. • This information can be put into a burn down chart that shows how much work needs to be done and how long its taking or may take.
  27. 27. 27 SPRINT PLANNING • A selection of what user stories can most realistically can be done in the first sprint; is taken from the product backlog and put into the sprint backlog. • Sprints can be 1 week, 2 weeks or 4 weeks in length. But they are never more than a month or 30 days in length.
  28. 28. Product Backlog > A prioritized list of work for the entire product. E.g., user story 1, user story 2, etc… (This may not appear on the board as it will be the initial wish list of the product that is being made / developed). Release Backlog > A subset of the product backlog that you are targeting for completion for the next or first release. E.g. user story 1, user story 2. (Technically in scrum you can release at any time and you don’t need a backlog to do this). Sprint Backlog > A subset of Release backlog through a set of detailed tasks/user stories. E.g., (user story / task 1, t 2, t 3) Please note some teams use a release backlog, although this is not recommended by some people working in Agile. Please see link and blog below for more on this The slide below is a high level over view of the Agile work flow process. RELEASE PLANNING / BACKLOGS / SPRINTS 28
  29. 29. Working Product Product Backlog Sprint backlog (may be repeated continuously) Working Product Product Backlog Release backlog 29 Sprint backlog (may be repeated continuously) RELEASE PLANNING / BACKLOGS / SPRINTS
  30. 30. BURN DOWN CHART • If you have 10 user stories in a sprint backlog and each has been given roughly the same time to complete. For example each user story will be about 10 working hours. Then after 50 hours roughly half of the sprint work would have hopefully been done. • As mentioned some teams may not use hours for estimates. Instead use, user stories or tasks for the burn down chart. • If a certain amount of user stories or tasks is being done a day, this can also give a great estimate on how many more days it will take to complete the sprint! E.g. 3 tasks are being done a day. This means 10 more tasks, will take about 3 days. 30 • There are various ways of estimation in Agile. An ideal approach may not be to estimate in hours.
  31. 31. SCRUM / STAND UP MEETING 31 • As part managing the project - 15 minute stand up or scrum meetings are held each day. • Each team member will say what they are working on and what they will be doing today. Also they can raise any issues or concerns. • On a Scrum project, there are three main roles: Product owner, Scrum Master, and team. The Scrum Master should act as the team's coach. Helping team members work together in the most effective manner possible.
  32. 32. RETROSPECT POSSIBLY CONTINUOUS DEVELOPMENT • A retrospective is usually done at the end of a sprint. It very simply looks at what went well and what didn’t. What could be improved for the next sprint. • They are different ways of doing retrospectives. Some of which may just be a brain storming session with the whole team. 32
  34. 34. Case Study: Agile Project Management for Government: The Success of the FBI Sentinel Project: Please see below for a very interesting and brilliantly written case study in Agile being used at the FBI. This Case study was written by Brian Wernham. Please double click icon to open. 34
  35. 35. REFERENCES 1. Gerald M. Weinberg, as quoted in Larman, Craig; Basili, Victor R. (June 2003). "Iterative and Incremental Development: A Brief History". Computer 36 (6): 47–56. doi:10.1109/MC.2003.1204375. ISSN 0018-9162 2. 3. Evolutionary Project Management (EVO) 4. 5. ^ Larman, Craig (2004). Agile and Iterative Development: A Manager's Guide. Addison-Wesley. p. 27. ISBN 978-0-13-111155-4 35
  36. 36. RESOURCES AND LINKS Scrum the story of an Agile Team (right click to go to website) 36