07. Project Management

Industry compared to SENG302:

• Scrum masters usually normal developers: saves money
• Focus on the product, not the developers
  • As long as Moffat is in charge, there will never be real customers (again)
• Efficiency: streamlining resources and money

SENG302 teaches you an ideal way that software development should work, which businesses which may not follow for efficiency reasons.

Exercise: Design a Software Methodology

Exercise: design and justify a software methodology that will replace current agile methodologies:

• Description
• Timeline
• Roles, ceremonies, events
• Processes

Use limited subset: Assume: Company building project with its own PO (not an agency building products for an external customers):

• Stakeholders = company staff + end users
• Product manager: developer in charge
• Specialized developers
  • Sub-teams
    • Team lead: normal developer
      • Team lead in charge of feedback
  • Shared backlog visible to everyone
  • ‘Exchange’ programs: peer review code from other sub-teams to get a better idea of the challenges faced outside their own sub-team
• Agile but not agile
• Development cycles:
  • Interview and gather feedback from potential end-users
    • Determine how the product being built will fit into their workflow
    • PM picks features
    • … Isn’t this Agile
  • Continuous development: ship as soon as a feature is done
  • Team meetings:
    • Weekly meetings within sub-team; team lead
    • Developer adds log/message as task is completed
  • Gather feedback
    • Dev team also spends some time as customer service
• 20% of developer time also spent on whatever they want: QoL improvements that never get prioritized

Other teams:

• Not scrum 1:
  • Stories planned
  • Sprint length determined by customer
  • Daily stand-ups
  • Informal weekly demos
• Pirate:
  • Captain: PM
  • Quartermaster: represents team
  • Daily standups, must be virtual
  • Three week sprints, one week verification/validation, documentation etc.
    • Anything you should have done but didn’t do during the sprint
  • Weekly planning meeting
• Chaos engineering:
  • Team leader: unilateral authority. Rotates every sprint
    • Abuse authority, get screwed by the team next week
  • Week long sprints
    • No formal planning beyond this point
    • Team can discuss among themselves knowing the rotation order
  • Negotiates with PO, but team leader has control
    • PO doesn’t own the product
  • Anything not completed gets dropped; up to the new team leader to decide
  • Meeting at start of the sprint: task delegation
• Distributed team
  • Team representative summarizes work and presents to PO
  • Retros every month: written report
• Variable teams
  • Scrum as a base
  • No estimates: tasks discussed in planning period, but not estimated
  • Team chooses sprint duration
  • Team decides number of developers each sprint
    • Developers not part of sprints work on general codebase issues
  • Randomized task allocation
  • Tasks should all work towards some small theme/story
• Continuous
  • PO: reviews code
  • Planner: generates tasks, estimates
  • Testers: TDD
  • Developers: develop
  • Daily stand-ups
  • Monthly process review: entire team
• Not scrum 2:
  • Scrum, but even more agile
  • Stories with ACs defined by PO
  • Day of spikes to research
    • Sprint length defined by this
  • Tasking done by developers as you go: no estimates
  • Team leader acts as team’s task reviewer
• Genetic algorithm
  • No planning, two week sprints
  • Half of the products die
  • Products randomly merged together into new products
    • How? Git merge…
    • Developers merge as they see fit; could completely remove a branch
  • All products get deployed: product that makes the best money survives
  • All the different species are documented
• Zoom people
  • Agile/scrum, but better
  • Had no time to fix bugs etc.
  • Senior dev assigns tasks, with soft deadlines for each tasks
    • Also assigned to bugs/issues
  • No sprints: too much pressure to complete tasks on time
  • Daily update/progress message

Analysis:

• Most lacked justifications: why
• Principles: must mention testing, technical debt, quality
• Comments:
  • Shows difficulty of coming up with a good process
  • Large companies:
    • Different departments do different work and have different requirements, leading to each team has its own process/methodologies
    • Internal/external products, small/large organizations
  • Most were based around Agile
  • PO role varied from God to no influence

Project Management

• Waterfall
• Agile
• Scrum
• ScrumBut
• ScrumAnd
• TODO

Product manager:

• Fredrick Winslow Taylor, 1856-1915
  • ‘Father’ of scientific/modern project management
  • Documented labor processes
    • How much raw material is coming in, how efficient is the output?
  • Standardized processes and measured performance
  • Aimed at business owners:
    • Can reduce labor cost by doing XYZ
    • Wanted to get rid of unions: unpopular
    • Metrics used to measure individual performance: never do this
• Henry Gantt, 1861-1919
  • Focused on scheduling: task dependencies
  • Appealed to workers: short workweeks, higher pay
  • Created Gaant chart
  • Used by navy shipbuilders, WW1 logistics/supply
• Great depression:
  • Workers used to be employed at a single company for life
  • Workers laid off or companies fold down
  • Works Progress Administration: Hoover Dam, airports etc. build
  • Many projects in progress in parallel
  • Led to project managers
• Lockheed Martin: mounting missiles to submarines
  • Program evaluation and review technique (PERT) charts:
    • Optimistic time for project (best case)
    • Most probable amount of time (normal)
    • Pessimistic time (worst case)
    • Expected time (best estimate plus delays)
• PERT further developed by DuPont, Remington Rand:
  • Critical path method (CPM): tasks which, if delayed, delay the entire project
  • Critical path is the most important determinant of schedule
• PERT and CPM together:
  • Visualized dependencies for better understanding
  • Identified critical paths
  • Calculated project times: consider early start, late start, slack/delays for each activity
  • Probability driven: probability of completing at a particular time
  • Visual charts
    • Could get massive
  • Waterfall project management
  • Not good for:
    • Variability/uncertainties
    • Flexibility/changing scope
    • TODO
• Toyota: 14 Principles
  • Published 2001
  • Very large influence on software development
  • Car manufacturing: a lot of raw material and a lot of interdependent steps led to a lot of waiting time in case of delays
  • Each area had to have a lot of raw materials just-in-case
  • Goal: manage bottlenecks for each area in order to manage work in progress
  • Philosophy:
    • Base management decision on long-term philosophy, even at the expense of short-term financial goals
      • Ethical values: can do what you say
      • Cultural values
      • TODO
    • Create continuous processes to bring problems to the surface
      • Eliminate waste through continuous management
      • The product can continue as long as the customer keeps paying us: iterative and continuous
    • Use ‘pull’ systems to reduce overproduction
      • Raw materials ‘pushed’ into the next steps
      • Rather, work should be pulled from the steps before
        • If customers don’t need the product, nothing should get made
        • Snow-ploughing: tasks get pulled to in progress when a task gets done
    • Level out workload
      • Reduce unevenness
      • Consistent, sustainable stream of work
      • Reduce muri TODO
    • Culture of quality
      • If a problem is found, fix it
      • Get quality right the first time
      • Refactor continuously, re-engineer rarely, rewrite never
      • Measure and pay off technical debt
    • Process for continuous improvement
      • Kaizen: continuous improvement
      • Empower employees: sof-organizing, self-directed teams
      • Inspect and adapt
      • Processes: review, retrospectives, stand-ups
      • Reflection
    • Efficient workspace, use visual control
      • Task board
        • Use often and regularly
        • Keep in a prominent place
      • Red/green: always know the current status
      • Visualize pipelines, builds etc.
      • Place retro items
      • TODO
    • Use reliable, thoroughly-tested technologies
      • Use the appropriate technology for the job: don’t push technology onto the project
      • Applies to languages, frameworks/libraries, design patterns
    • Grow people/leaders who thoroughly understand the work, philosophy, and who will teach it at others
      • Scrum masters
        • Should not be developers
        • They should be learning about whatever they will be teaching the team
        • They should be teaching/educating the customer so that they understand what they are doing and what the team expects from them
      • Flat hierarchy
      • TODO
      • A ‘learning organization’
        • CMMI: organization must improve
    • Develop exceptional people/teams who follow the organization’s philosophy
      • Success is based on the team, not the individual
      • Remove silos, lower bus factor
      • Team, not individual code ownership
        • Javadoc: has fields for author name
      • Create and document processes, principles
      • Flat hierarchy: self-directed, empowered teams
        • Requires even experience
        • TODO
        • Initiative: someone must take the initiative and drive things forwards
      • Teach individuals
      • Continuous improvement (Kaizen)
    • Respect your extended network and help them improve
      • Suppliers etc. are also stakeholders
      • Teach customers (e.g. methodology being used, what is expected of them)
      • Update customers/stakeholders often and get feedback from them
      • Use processes that increase communication and transparency
    • Experience it first-hand to understand the situation
      • Waterfall approach: what the customer asked for was not what the end-user actually needs
      • Need to see for yourself to understand the situation
      • Empathy driven design
      • Think about the customer’s environment
        • e.g. network speed, computer performance, familiarity with computers
    • Make decisions by consensus, consider all options, implemnt rapidtly
      • Candidates olutions with pros/cons
      • Spike and prototype
      • No hero culture: team is involved in decisions
      • High communication: task board, logging, communication tools, ceremonies, meeting
      • Fail fast, fail often
    • Become a learning organization through relentless reflection (hansei) and continuous improvement (kaizen)
      • Document learning from previous projects
      • Evaluate, measure, analyze, reflect
      • Use metrics to improve
        • e.g. Sprint velocity
        • Not often done in business: no immediate ROI
        • Need to understand what the metrics mean
        • Tools aren’t very good
          • Defaults settings must be changed: otherwise can get overwhelmed
      • Use tools to give real-time metrics
      • Standardize across the organization, but with flexibility built in
        • Communicate findings across the organization

Three M’s (wasteful actions)

Used in Lean

1. Muda

• Wastefulness
• Work that adds no value
  • Goldplating
  • Things you think the customer may need but never will
  • Over-engineering
  • Compare to work that adds value but is not recognized

2. Mura

• Irregularity/lack of uniformity in the work
• Variability that causes muda
• Kanban attempts to address this

3. Muri

• Don’t overwork the people or the equipment
• Leads to unsustainable development
• Prone to failure

Waterfall

There is no development method called ‘waterfall’: it is an umbrella term.

Software development life cycle (SDLC):

• Requirements analysis
  • A huge amount of documentation, UML diagrams etc.
  • Legal representatives from both companies often involved
    • Who’s fault is this?
• Planning
  • Every decision signed off by management and/or the customer
• Software design
• Development
• Testing/Validation
• Deployment
• Maintenance

Waterfall can be iterative: a lot of overhead.

Why use waterfall?

• Scheduling: dependencies known and can be time boxed
• Clients can give them requirements and then ignore them until it is done
• For projects with known scopes
  • Agile projects have no ending
• For critical systems:
  • Avionics/space, medical, infrastructure
• Low-trust environments:
  • Government departments
  • Big institutions
  • When someone needs to be blamed and pay up

Waterfall TOOD:

• Distinct sequential phases
• Well known problem:
  • Low amounts of research needed
  • Low amounts of flexibility needed
• Predictable:
  • Dependencies can be mapped out
  • Known architecture and technologies
• Very high quality is required
  • Time devloted to getting high quality
• Higher expense built in (known phases)
• Low-trust between the business and customers

Agile is very expensive:

• Changing requirements leads to more re-engineering
• High technical debt: fast time to market, but has costs further down the road

Extreme Programming (XP):

• Focus on adaptability (rather than predictability)
• Assumes that requirements cannot be predicted at the beginning of software projects
• Four values
  • Improve communication
  • Seek simplicity
  • Seek feedback
  • TODO Courage
• Four activities:
  • Coding
  • Testing
  • Listening (to customers, to the team, to stakeholders)
  • Designing
• Good programming practices pushed to the extreme (or what was considered extreme when it was created):
  • Code reviews:
    • Reviewed all the time through pair programming
    • Rather than at the end
  • Testing:
    • Test all the time
    • Maybe through TDD ()
    • Everyone tests, including the customer
  • Design:
    • Everyone is responsible for the design
    • Refactor continuously
  • Simplicity:
    • Start with the smallest, simplest solution
  • Integration testing:
    • Integrate multiple times a day
  • Short iterations:
    • Make iterations as short as possible
    • Release plan(months), iteration plans(weeks), acceptance test (day), stand-up meeting (day), pair negotiation (horus), unit testing (minutes), pair programming (seconds)
  • 12 practices
    • Planning games, user stories
    • Small releases
    • Metaphors
    • Simple design: YAGNI
    • Testing
    • Refactoring
    • Pair programming
    • Collective ownership
    • 40 hour weeks: sustainable development

Agile principles:

• Agile is not a methodology
  • You do not ‘do’ Agile
  • There are other methodologies/frameworks that follow the Agile principles
• Iterative, structured
• Very product-based: product and quality matter
• Very team-based: self-organizing, flat hierarchy
• Principles:
• Values:

Lean:

• Came from manufacturing
• Created by the Lean Enterprise Institute (1997)
• Focuses on eliminating waste
• Onlly have what we need at the point in time where we need it
• Five key principles:
  • Identify value:
    • What does the customer need?
  • Map value stream:
  • What steps and activites are required to make and deliver the product?
  • Eliminate steps that do not create value
• Create flow:
  • Remove bottlenecks
  • Keep value-occurring steps in tight sequence
• Establish pull:
  • Just-in-time delivery: customer gets what they need as they need it
• Seek perfection:
  • Continous improvement

Scrum:

• Flexible but formal
• Framework - does not define processes
  • Does not define roles, how to test etc.
  • Simply gives you a structure to work around
• Ceremonies
• Roles
• Regular, fixed-length sprints
• Event-driven
• Fairly predictable with defined, bite-size goals
• Small, self-organizing teams
  • Can have teams-of-teams
  • Orthogonal teams (e.g. UX team responsible for all product UX within a organization)

Kanban:

• Very flexible
• Concerned with throughput
• Maximizes efficiency/flow
• Not as much process: no ceremonies, no roles
• No iterations: continuous flow
• Good for continuous production
• Not concerned with teams

Scrumban:

• Scrum structure with Kanban’s flexibility
• Short iterations
• No roles
• Not concered with teams: can conatin generalists and specialists
• Daily standups and optional ceremonies
• Sometimes called ‘controlled Kanban’

Project Managment Certifications:

• A few avaialble. The most popular are:
  • Project Manaagement Prfessional (PMP) certification
  • Offered by Project Mangemetn Institute (PMI)
  • Use Project Mnagement Book of Knoweldge (PMBOK Giude)
  • Principles of project management
  • TODO TOOD
• PRINCE2 Principles
  • Continued business justifiation: tasks must have a clear ROI and the use of time/resources must be justified
  • TODO
  • Manage by stages
  • Manage by exception:
    • Measure delegated authority and outcomes within the process
    • Create contingencies and action plans
  • Focus on products:
    • Product requirements determine work activity, not the other way around
  • tailor to suite project environment
    • highlight the necessary risk, time, capability, size, complexity and cruicial components for the project
    • Use the tools (e.g. langague, frameworks) that best fit the enevironment