Agile Project Management Overview

Agile Project Management

Agenda

• Project recap
• Starting a project
• MOSCOW
• User stories
• Planning
• Cynefin
• Project teams
• Tasks for the practical

Project Recap

• Assessment 1 requires 1500 words
• Assessment 2 accounts for 30% of the total unit grade
• Assessment 2 is an exam
• A project is a temporary endeavor to achieve a defined benefit
• Agile methodologies can include DevOps, DSDM, Kanban, Lean, Lean Start-up, Scrum, and XP

Team Roles in Agile

• Agile has varied roles depending on the type used, the organization's size, and other factors
• Roles can have different terms - Customer, client, sponsor
• Other roles include Product Owner, Scrum Master, Project Manager, Coach
• Your project group makes up the development team, technical team, programmers

Starting a Project

• A business case is created to explain why a project is needed, and requires continual monitoring
• A project mandate can range from a detailed contract to informal notes

Agile Teams

• Team stability is important, as changing teams can cause disruption and wasted time
• A skills gap analysis helps to bring the team's skills up to speed
• Dedicated, cross-functional, self-organized, self-managed, size-limited teams that take individual ownership are most effective

Effective Team Members

• Ideally, team members are T-shaped: possessing reasonable knowledge across many areas with expertise in a narrow field
• Early skills audits help to optimize team performance
• Tasks that are too difficult can disengage member
• Tasks that are too easy can bore members
• Pair programming and job swapping can help team members improve their individual skills
• Factoring adequate time to develop essential skills is crucial at the start
• Maintaining a common goal of a happy client, operational artifact, or good grade is key

User Stories

• Epics are high-level stories which are coarse-grained
• User stores are redefined to become more specific as the project progresses, following the format:
  • As a
  • I want to
  • So that
• Example:
  • As a stock controller
  • I want to know if my stock level is very low
  • So that I don't run out and fail to fulfill a customer's order

MOSCOW Method

• Defining product requirements involves tradeoffs
• Too many requirements restricts the project
• Too few requirements can lead to misunderstandings
• The MoSCoW method prioritizes requirement as Must have, Should have, Could have, and Won't have

Product-Based Planning

• Start with broad entities
• Break into components
• Continue until there are discrete units that cannot be broken down further
• These discrete units are the products the team delivers

Work-Based Planning

• Uses verbs instead of nouns to drive the project
• Focuses on identifying the tasks to be done instead of listing what must be produced

Choosing a Project Management (PM) Approach

• Depends heavily on the product to be created
• Consider whether the product is novel or has been done before
• Use lessons from previous projects and experience within the team
• The Cynefin framework can help with this decision
• Cynefin is pronounced "ku-nev-in"
• The framework describes the relationship between the cause and effect of complexity

Cynefin Framework

• Clear: obvious relationship; solution is clear; checklist approach works; best practice
• Complicated: may be more than one solution; some expertise/analysis required-good practice
• Complex: solution may need to be uncovered step by step; can only be understood in retrospect-emergent practice
• Chaotic: no apparent relationship; novel situation
• Disorder: no clear agreement between Clear and Chaos

Agile Litmus Test

• Does the project support early and continuous delivery of valuable software?
• Does the project welcome and take advantage of change?
• Does the project lead to and support the delivery of working functionality?
• Are developers and PM working together with other stakeholders?
• Does the environment support the team to get the job done?
• Does the team communicate in person?
• Is progress measured by the amount of functionality?
• Can the pace of development be maintained indefinitely?
• Does the project support technical excellence and design that allows for future changes?
• Is work being maximized, doing as little as necessary to achieve our aim?
• Is the team self-organizing and self-managing?
• Is the team reflecting at regular intervals and adjusting their behaviour accordingly?

Practical Information

• Join a group in the practical session if not yet in one
• Attend practical sessions if wanting to change groups
• All group members must attend practical sessions
• The project will end in Week 10