Week 6: Small-team Project Management#
Studio Abstract#
In this studio, we will investigate effective task management and planning for small teams (3-5 people). We will also look at setting up the Github Projects tool and how to set up tasks and notifications. Finally, we will also ask you to do a short self assessment on your performance in the course so far.
We will address the following activities and exercises in studio 3.
Basics of managing a small-team project
Setting up Github projects
How to create tasks
How to set up notifications
Github Project start-up Activity
Self assessment
Using team planning tools in COMP1100/COMP7110#
We expect teams to use the Github Project tool to track the team progress in this this course.
Adding and closing tasks is straightforward and easy. The difficult part is deciding what tasks need to be completed, and who will do what by when.
The small overhead of using the Github Project tool is paid back to the team by them being able to see who is assigned to what, when they have agreed to deliver it, and whether it has been delivered.
Effective Small-Team Planning#
⏱️ 15 minutes - Group
Devices closed for this exercise
Managing yourself is challenging enough, but imagine if each limb was its own person and the only way to control them is through an itemised daily schedule. Welcome to team planning.
In this studio, we’ll look at a simple but effective model of project planning for small teams, such as yours, and a tool, called Github projects for managing your team.
Fig. 31 Teamwork!#
In this course we recommend the use of Github projects, a team scheduling and planning application, but there are many other suitable tools.
Managing a small team: Who Does What By When#
The model of who does what by when is a simplified project management model, proposed by Manager Tools owner Mark Horstman. He agrees it is over-simplified, but the who, what, when trilogy is the most important three parts of project management.
All projects are completed by completing a series of tasks. It is difficult to know up front what all of those tasks will be. As a result, project management is a discipline in itself. For large-scale projects, even in the software industry, we may need multiple people to manage different parts of a project, and that could require using sophisticated project management tools, overview charts, etc.
But for projects with small teams of about 5 or less people, such sophistication is usually not necessary.
Further, all tasks are completed by people who are on the project. And people’s behaviour is often driven by deadlines.
So, during a small-team project, we just need to know three things: who does what by when.
No budget, no critical path, and no lengthy reporting. Note that budget IS important, but in small-team projects, especially start-ups, we see that: (a) budget is almost entirely taken up by the cost of people, so focus on people and the budget takes care of itself; and (b) budget is typically so front of mind that it does not need managing like our time.
Who#
People do tasks on projects. Tasks don’t get done without people. Great project managers know who is in the project and what they are doing.
As a team, we need to know who is completing each task so we can discuss with them, ask questions, follow up, and, ultimately, hold them accountable.
For each task on a project, ONE person should be assigned to do that, and that person is accountable for ensuring it is completed on time. If you see a task that requires more than one person, break it into smaller tasks (see more in the next step below).
Tips on defining who:
Each task should have one person responsible. If we have more than one, break it into smaller tasks.
Hold people accountable for completing tasks.
Does what#
Tasks are what make up a project. No project gets done if its constituent tasks are not done.
It is important to identify the tasks that need to be done in a project. We shouldn’t identify every task at the start of the project. This is a waste of time, especially in software projects, and doubly for innovation projects. Things change! Instead, we should have a high-level idea of where the project is going, and have clear tasks identified for the next 1-2 weeks.
Some tips on defining tasks:
Each task should be measurable. That is, it should be easy to tell whether it is done or not. For example, “Think about customer interview format” is not measurable because you can’t see my thinking. “Send draft interview questions to person X” is measurable, because it is clear whether I have sent it to X or not.
Make reporting part of the task. It is great when tasks are finished. It is much better when others in the team know that tasks are finished, especially if they are waiting on them. As part of a task, make reporting part of the task; e.g. “Check user story 7 into the repository and report this to person X”.
By when#
People hate deadlines. Actually, people hate having deadlines, but like other people sticking to their own deadlines. The fact is, deadlines drive behaviour. If university courses didn’t have deadlines, would you still submit all your work by the end of the semester?
Some tips on deadlines:
Make tasks that require no more than 5 working days; even less for most tasks. A week is about as far ahead as we tend to think. For example, if a task will take about 6 weeks, it is certain that there are smaller sub-tasks that can be done. “Conduct 70 customer interviews” could start with “Define customer interview questions”, then “Ask person X to check questions”, then “Interview first 5 customers to validate questions”, etc.
Make deadlines specific. For example, not “Next week” or even “Thursday 27th”, but “1pm on Thursday 27th”.
Shorter deadlines are often more effective. The famous Parkinson’s law is “work expands as to fill the time available for its completion”, which means: the more time we give people/ourselves, the longer we take. People will resist shorter deadlines, but seem to respond well to them. Longer deadlines do not drive behaviour. So keep deadlines short, but not so short that quality is affected.
Update the deadline if it is missed. We all miss deadlines sometimes. In such a case, don’t just say “OK, please submit it soon” – assign a new deadline immediately: “OK, thanks for letting us know. Can you please get it to us by 1pm on Thursday?”
Summary#
Basic team management planning means knowing:
Who is doing each task.
One person per task.
Hold people to account.
What each task is.
Make tasks measurable.
Make reporting part of the tasks.
When each tasks is due.
Five working days maximum.
Make deadlines specific.
Shorter deadlines drive behaviour.
Update deadline if missed.
Task planning exercises#
⏱️ 15 minutes - Group
Devices closed for this exercise
As a team, get together, brainstorm, and write down ALL of the tasks that you can think of for your team for the coming two weeks. (Hint: look at the course schedule).
Think about things to do with setup, project work, even scheduling meetings.
For each one, write down: who does what by when.
Your legends will be working with you to give feedback on your task breakdown.
Github Project setup#
⏱️ 30 minutes - Group
Devices open for this exercise
In this project, you will use Github projects. It allows us to define tasks, assign them to people, and give them due dates: who does what by when!. It also supports a whole other range of nice features that you may wish to explore independently.
You already have a Github account from an earlier studio. Once you log in, use the following tutorials to learn how to use Github.
Create a project#
One team member should create a repository project. To do this, navigate to your team repository, then select ‘Projects’ from the top menu, and then select ‘New Project’.
Note: You need to create this from your repository, otherwise it will be public to anyone in the organisation, who will be able to change tasks.
We suggest using the template called ‘Team planning’, but you are free to try others if you want.
You MUST name your project using following format:
[Day]_[Time]_Team_[XY]
where Day is either Mon, Tue, Wed, etc., Time is the start time of your studio such as 11am, and XY is your team number using two digits.
For example: Mon_11am_Team_02 — so the same format as your MS Teams channel and Github repository.
For further details, read:
Understanding project boards#
You should now see a project board. If you have selected the ‘Team Planning’ template, along the ‘Backlog’ tag, you will see three columns: Todo, In Progress, and Done.
These three labels are a simplified Kanban board, which track:
Todo: the backlog of tasks that a team needs to complete.
In Progress: the tasks that the team is currently working on.
Done: the tasks that the team has completed.
The idea is that, when teams/individuals decide that tasks need to be done, they add the task to Todo.
When an individual starts on a task that is in the Todo backlog, they move it to In Progress, so their team members know what they are working on.
Finally, when it is done, tasks are moved to Done.
Feel free to add more lists if your team want. For example, Kanban boards often have ‘Planning’ in between Todo and In Progress; and ‘Review’ between In Progress and Done.
Iterations#
Many projects (including the project in this course) are done in iterations. It is useful for Github projects to know the iteration dates, so you can ‘tag’ tasks, etc., with the iteration, making it easy to navigate by filtering things only from the current iteration, for example.
One team member should:
Go to the main page of your Github project.
Select the three dots ‘…’ from the top right of the page.
Click ‘Settings’ and then ‘Iteration’.
Create Iteration 1, Iteration 2, and Iteration 3 using the dates from the course profile.
Creating tasks#
Next, we will start adding tasks from the earlier exercise. If you run into trouble, consult the documentation:
Create tasks: Create new tasks (items) for the tasks that you are responsible for. Give the task a short, meaningful title, and add a description in the ‘Description’ field is more information is required; e.g. requirements, links to data source, etc.
This is the What in Who does what by when.
Click on the task name, and another window will appear, with a heap of information. Do the following:
Tag people: At the topic as ‘Assignees’, which are the people responsible for completing the tasks. A task can belong to more than one person. Select who is responsible for the tasks that you are adding if you are not the only person responsible.
This is the Who in Who does what by when.
Add due dates: Find the ‘End Date’ and assign a due date for the task.
This is the By when in Who does what by when.
Add iteration: Find ‘Iteration’, click on this, and assign the right iteration (Iteration 1, 2, or 3).
Tip: For any task, the due date should be before the end date of the iteration, but Github does not warn if it is not.
Seeing the due date#
Close the task so you can see the project board again. You will note that the due date does not appear in this view.
To make it show, select ‘Backlog’ (or the name of the view that you are using if you didn’t select the ‘Team Planning’ template), then ‘Fields’, and then ‘End Date’.
Filtering#
From the main project board, you should see a search bar with ‘Filter by keyboard or by field’. Here, you can filter to see you own tasks only, by name, etc.
One ‘hidden’ option is to filter by iteration. Type “iteration: ” and then scroll down to see Iteration 1, Iteration 2, and Iteration 3. This is useful to focus only on tasks that are relevant in the current iteration. You can search “iteration:@current” for this too.
And your done!#
You now have a project management system that is suitable for small teams!
Your responsibility is to now use this task tracker and look at it when you want to know what others are working on.
Reflection#
⏱️ 10 Minutes - Class
Devices closed for this exercise
Now that you have completed this, reflect on the following with the class:
What is one key thing you will take away from this studio for your project and why?
In what ways did this studio change your understanding of managing team dynamics?
Have you used Github projects or any other similar tools, such as Trello or Jira? If so, share your experience with the class.
Additional Resources#
More tutorials and documentation can be found at Github’s online guide:
🌐 [https://docs.github.com/en/issues]
In particular, a few features are relevant for those wishing to use Github further:
Break#
⏱️ 10 Minutes
Self assessment#
⏱️ 45 Minutes - Group and Individual
Devices required for this exercise
You can find a spreadsheet that your legend will use to give you feedback after each iteration.
With the submission due this week, we want you to take some time to assess your own progress, and to think about whether there are a few small changes you can make before the submission to make your contribution clear.
This activity has four parts:
One team member should download from the link above and put it in the ‘Files’ of your MS Teams channel.
[5 mins] Each person should open this and take 5 minutes to read (and remind themselves) of the competency criteria that we use to assessment individuals in the course and the levels that we grade each at. Notice that the fifth columns is called ‘Add criteria here’ – and all cells in the columns are empty.
[20 mins] Break your team into two sub-teams:
Team A: Read the eight competency criteria for the ‘Team’ assessment (in the first table) and come up with 2-3 criteria for each competency that you think would demonstrate that the competency has been achieved. For example, under the 2nd competency on experiments, one criterion may be ‘All hypotheses are testable, simple, clear, and ethical’. Split up the competency so each team member does this for 2-3 competencies. Take it seriously but don’t overthink it.
Team B: Read the six competency criteria for the ‘Individuals’ assessment (in the second table) and come up with 2-3 criteria for each competency that you think would demonstrate that the competency has been achieved. For example, under the final competency on professionalism, one criterion may be ‘Shows up to meetings, studios, and 1-on-1s on time, and participates meaningfully.’ Split up the competency so each team member does this for 2-3 competencies. Take it seriously but don’t overthink it.
HINT: This task may require you to revisit the course notes.
[20 mins] Once all criteria have been defined, each team member should make their own copy of this file, and conduct a short self assessment. Select the appropriate rating under the ‘Assessment’ column for each competency, and write brief feedback to yourself that answers: where it is demonstrated that I have achieved this competency? It is important to ask yourself: yes, I’ve learnt this, but is there evidence available to my legend that I have learnt it?
Important: Be honest with yourself. This is not part of your grade and we won’t be using this to judge your actual contribution – this is to help you reflect on the quality of your own work and how others (your legend!) will see it.
Exit ticket#
Teams: Show your legend your Github project created using the format
[Day]_[Time]_Team_[XY].Teams: Show your legend the tasks that you have assigned to complete for the remainder of iteration 1, which clear show Who does what by when.
Individuals: Show your legend your self-assessment on your demonstration of the capabilities so far.
Bonus: It’s dangerous to go alone! Take this.#
⏱️ ∞