SENG2021

Project Management 🏈

Before defining a solution (our design) we must first understand the problem we're trying to solve (our requirements)
What does good look like?
Define outcome/endstate first
Then come up with a solution
Avoid creating solutions to problems that don't exist
Avoid following processes and practices without a logical basis

What is the problem we're solving?
How will we solve it?
Different people in the team will work at different levels of abstraction
One person's design is another person's requirements
Power of teamwork - split responsibility from those who define problems to those who solve them

What's the difference?

Problem-solving; thoughtful planning and designing; seeing things through from end to end;
Defining the problems to be solved, not just finding solutions
Dealing with the unknown, deal with ambiguity
Learn to deal with unknowns gracefully as they arise
Domains are often highly specific, nuanced and complex
When we spend time with a problem, the problem space grows around us
Transformation of the unknown into the known
Detective work

Process of understanding the problem to be solved
Iterative process
Team process
Hardest for people new to the team / junior developers
As people become more experienced, they can use their context to aid their understanding
Research, asking questions and clarifying unknown areas is essential

We make assumptions all the time, implicitly
When understanding software requirements, we have to make assumptions in order to understand efficiently
Three types of assumptions
- Reasonable assumptions that don't cause problems/breakages
- Reasonable assumptions that do cause breakages
- Unreasonable assumptions

Sometimes we need to start actualising solutions in order to better understand what the problems are
During the process review, our requirements are often clarified as much as our design
Our changes/work is validated as well is verified
Need to balance between spending too little and too much time at the beginning understanding the problem up front

Pair programming - a highly useful technique for lifting members of the team up
People bring their context and experiences to solve problems
Role of senior engineers is to mentor and coach junior engineers, provide context and guidance

Too much, too little
Working software over comprehensive documentation doesn't mean no documentation
Since You've Been Gone
Fast-track people so that they don't have to tread the path that you have already
Some things can't be documented

Grooming - a process of preparing tickets for the next sprint of work
Grooming meetings include:
- Removing redundant or outdated tickets from the backlog
- Splitting tickets into sub-tasks/further tickets to modularise problems
- Ticket reporter / feature lead will often explain the ticket to the team
- Team has the opportunity to ask any questions and clarify details in ticket description
Allows the entire team / stream to understand all the work being done in the team
Provides further context to the team on their work
Usually completed once per sprint (to groom tickets for the upcoming sprint)

An agile meeting (can be combined with grooming)
Completed once per sprint (to estimate tickets for the upcoming sprint)
Each ticket to be completed is allocated a number of story points
Allocating story points is a democratic team process (vote and discuss)
Story points are not a measure of time - different tasks will take different amounts of time by different team members; time isn't an accurate measurement here
Instead, we measure relative effort

Fibonacci scale used to allocate numbers
- 1, 2, 3, 5, 8, 13, 21
Teams should determine their own standard for ticket estimations, with examples of work
An example of a standard for ticket estimations
- 1 - very trivial change (e.g. feature flag cleanup)
- 2 - minor change (e.g. fixing some broken unit tests)
- 3 - moderate change (e.g. adding a new suite of tests to a function in an API)
- 5 - significant change (e.g. hard bug fix, large spike/investigation)
- 8 - can often be broken into smaller subtasks, or is highly complex
- 13 - this should be broken down into subtasks
- 21 - Epic (contains a series of tasks to complete)

Team/people needs
- Allows engineers to contextualise their work
- Manages expectations
- Get commitment from the team
Task needs
- Forces us to ask questions around a task, discover unknowns and grow the problem space
- Useful for synchronous estimations to spark these discussions
- Shifting left and moving discovery earlier in the process
Organisation/planning needs
- Allows teams to plan capacity
- Allows higher management to see team progress and measure reliability
- Allows for optimisation of throughput

Special type of task/ticket that involves investigation rather than implementation
Examples of spike tickets
- Investigate why there is a spike in errors on an API
- Research into which language we should use for our backend
- Design a database schema
Often will produce a document / report / investigation findings as a result that is taken into further tickets
Can break more complex tasks down into spike / design / implementation

Even though we work in an agile way and release regularly, we still have a long-term plan of where we're going
Start with a problem:
- Understand the problem space
- Define the high level solution
- Create a roadmap of how to get to the desired endstate
Roadmaps involve
- Timelines - estimations for how long tasks will take (this is hard!)
- Sprint plans
- Resource allocations - who will be working on what?
- Considerations
Completed by feature leaders / engineering managers
Need to be able to adapt and change the plan
Can use Gantt charts to visualise roadmaps