Project Management

This page covers how the team manages the mini-projects of the Tick Tock cycle.

Background

Traditional project management models (“waterfall”, “v-model”, etc) tend to fail with software projects because software is different. This (quite old) essay on the nature of software engineering does a nice job of describing how software is different from traditional engineering: Code as Design.

Agile project management practices are more suitable to software because they leverage its strengths. The Agile Manifesto is the classic statement of values that guide agile projects.

Software is hard to measure. This book outlines the typical agile techniques for estimating and forecasting a software project: Agile Estimation and Planning.

Our process is Scrum-like. Much has been tailored to suit the team we have. A decent read on the nuts and bolts of Scrum is: Succeeding with Agile or from the original Scrum Guide.

We use Jira to drive planning and sprint meetings. Setup notes here: Jira Project Setup

Plan

Envision

Envisioning is about understanding the problem. Sit down with the client and figure out what problem they are trying to solve. Take notes. Draw pictures. Ask why. Clients will tend to use words that sound like software design (ex: “I need a button to save“) this is just their way to describing an intent. Try to find out why they need, ex: they want their data to persist. Try to sense what things are the most important.

Capture

The goal of a “user story workshop” is to turn a client’s needs into a backlog of high level requirements called user stories. Take what you have learned from envisioning with the client and rehash it with some team members. The classic format for a user story is:

As a <stakeholder>, I can <achieve goal>[, so that <value is achieved>]

Many projects build upon previous work. In this case, it is also possible to have defects included in the scope for a project (ex: client asks for a fix).

Estimate

Sit down with the team and estimate the stories using story points. This process is almost like a second pass through the stories created in the workshop. Estimate stories using story points. Add acceptance criteria to the stories to clarify what was being considered for the estimate, ex:

As a user, I can choose a feedback image

• user can select an image file from disk
• image is displayed in the feedback cell
• user notified if an image isn’t valid

Some stories will be way too large for the team to complete in one sprint. The team should try to break these down into smaller stories using spitting techniques.

For larger projects with several releases, an “iceberg backlog” approach can be used where only the highest priority stories in the first release are broken down.

Defects included in the original project scope should be estimated in points. Defects are hard to estimate. It is ok to increase story point estimates to capture the “worst case”. This book: Agile Estimation and Planning describes ways to capture risk using a geometric mean of two estimates: one that has 50% chance of being right and another with a 90% chance of being right.

Tasks are not estimated because they are just steps for delivering the scope (stories, defect fixes). For example, “set up GitHub” is just a step towards delivering the story “user can chose feedback image”.

Prioritize

Meet with the client and step through the estimated backlog of user stories. It’s likely additional stories will be generated in this conversation. Some stories may end up being deleted.

Identify what stories are high priority and which ones can be saved until later. The client needs to understand that low priority stories may never get done.

Forecast

With an estimated and prioritized backlog of user stories, a forecast for the project can be made. Duration of the project is derived from the total story points divided by the teams historical velocity.

It’s pretty normal for the forecast to go way beyond the expected project timeline. When this happens, work with the client on what to do. Low priority stories can be removed. High priority stories can still be split and low priority portions removed. The project timeline can also be extended.

Execute

Kick Off

Project kick off is when the team and client meet to start the project. The purpose of the meeting is to communicate to the team:

• roles (who is the client? who is the team lead? who is on the dev team?)
• what problem are we solving? what is the goal? why do this?
• solution outline (rough sketches help, avoid excruciating detail)
• project plan / release plan / schedule
• process (planning meetings, standups, demos, etc).
• communication plan (use slack for dev discussions, emails for client questions, etc)
• tools (ex: slack, github, jira, confluence, unity, python)
• next steps (ex: planning meeting with devs this afternoon)

Plan

Plan each sprint with the development team.

The team lead comes prepared with a prioritized backlog. The team pulls work into the sprint until they feel the sprint is full, ideally choosing the highest priority work. The team lead can negotiate with the team on priority / order of completion.

Discuss what will be demonstrated to the client at the end of the sprint (assuming everything goes as planned).

Demo

A the end of the sprint, the team demonstrates what was completed. For example, demonstrate that the planned user stories are satisfied.

Ideally, the client attends the demo to provide direct feedback. When that isn’t possible, the team can still demo to themselves and reflect.

Retrospect

The demo is the agile “canary in the coal mine”. It’s a test of the overall process - can we deliver what we promised? If not, how come?

Retrospectives are a good way to reflect on problems encountered and to brainstorm ways to avoid the problem in the next sprint.

Monitor

With every sprint, the project lead shall assess if the project is on track and take action if not.

Jira’s version report is quite useful for this. It requires a version with a start/end date and a set of user stories with story point estimates. Jira will automatically keep track of story points completed per sprint and use this to forecast how many more sprints will be required to complete all the work. It typically requires 2-3 sprints before the forecast is useful (as first sprints often have a velocity of zero).

Manage

The project lead will have to manage project scope continuously (that’s just how it is). There’s several different situations where this will come up:

• Regularly grooming the backlog - ensure the highest priority items are at the top, ready for the next planning session. The project lead is responsible for ensuring that items in the backlog have descriptions and are correctly entered as stories, tasks or defects.
• Discovered work - Sometimes we forget to add something to the plan. This is discovered work. The project lead decides if the new work is in scope and how that impacts the plan. Critical items can be added to the plan by pulling other items out. Alternatively, the project duration could be extended, etc.
• New scope from the client - new scope (stories) can be added with the understanding that this pushes some other feature out of the plan, or the project duration is extended. For example, a 2 point story can be added to the backlog only if 2 points are removed.
• Defect management - Add defects to the backlog and prioritize. The project lead can decide if the defect is in or out of scope. Defects discovered during a project are typically not estimated. They are the ugly face of technical debt - reducing the team’s velocity and extending the project forecast.
• Responding to low velocity - If the project is going to be late, work with the client. What can be removed from the scope of the project? Can a story be sliced down to just the bear essentials? Or, can the project duration be extended?

Managing scope should always be the first reaction to schedule problems. There are other responses, but they don’t usually work that well:

• Lower quality (aka “cutting corners”) - This is almost always what happens. We try skipping steps, especially things like testing, documentation and meetings. If this is done for any appreciable length of time, the technical debt incurred will hurt the project. Ex: we shipped a broken product because we didn’t have time to test it… So, not only are we late and the client is mad, we now look incompetent.
• Work overtime - We all learn this bad habit in school. It works because school projects are tiny and typically isolated - you can crunch for a weekend and catch up with your life next week. This won’t scale for larger projects, leading to burnout, lower quality software and ultimately employee attrition and absenteeism. Nobody wants to work in your sweatshop.
• Add team members - Adding a team member in the last 2 weeks of the project will typically slow the team down and hurt schedule. This is because the new team member has to ramp up - by interrupting the rest of the team. If the schedule is long enough to accommodate a ramp up, then this can work.

Close out

At the end of the project, hold a retrospective to review what went well, what didn’t and what could be done better.

Handoff of deliverables to client.

Define a path for them to escalate issues (ex: how to get a bug fixed)

Archive any project artifacts as needed (ex: put final release someplace)