Welcome to your Live Project!
Projects run from start of October, to end of March, where there is a showcase event.
Project Time: 22 weeks
Team Size: 4-6 people
That's a long time, and alot to get organised. If you split the time up into project phases, it's much more managable. If you deliver regularly, you get plenty of feedback, and stay motivated.
We've split it up into weeks (blue), and sprints (green). We've made some project phases to indicate the activities which should be going on. We do this ourselves on the projects we do. It works really well, with a motivated team and enough people for the job. Working on this project, you'll need to work to this timeline.
The rest of this article is a guide on what to do and expect as you work on this project.
In this project you'll find a spreadsheet file which contains a tool to help you budget: Your Budget
Use it to figure out how much effort your team can commit to your project - and to imagine what it is possible to achieve, when you start to work out what needs to be done.
Like the diagram above, this tool splits your LiveProject into 22 weeks. But now there is a timeline for each of the people in your team. Put the name of each person next to a timeline, and ask them to fill in the hours they expect to be available per week. The tool calculates the total effort available for your project, in developer-hours.
Do this first, at the start of your project. It will be a baseline understanding of your team's effort commitment. It's a measure of your intention.
As you go through the project, you can use the tool to measure how much effort you can give to the remaining tasks, by simply setting the previous weeks' entries to none.
If you want to do this together, upload the file to Google Sheets - it will allow you to work on it simultaneously - but don't forget to download it again and check it in.
Throughout this guide, we've set a standard for effort: it will effect what you can achieve.
Minimum: 5 hours per person per week You'll get something out of the project, but you'll have to cut out alot of functionality. Make sure that you're up-front about this in your requirements sessions, so you can plan a minimal implmentation. Do spend enough time in the technical investigations, so you don't get a nasty surprise later on!
Expected: 10 hours per person per week With some good design and technical investigation, you will be able to produce a result which does the job on all counts. Be very aware that the tasks we have set you concentrate on results. There's alot you can do by using tools and frameworks that remove the writing boiler-plate code, and allow you to concentrate on what's important.
Stretch: 15 hours per person per week You're ambitious, and really want to use this project to learn some amazing skills. Be careful though! It's really easy to waste alot of time on a cool feature at the expense of one which is essential. Stick to the plan, and make the extra effort pay off for you.
Your team is built from individuals: it's up to all of you to figure out how your different skills and temperaments fit together.
Start off with knowing your self a little better; head on over to 16Personalities and take their free personality test it's based on Myers-Briggs personality testing. Sceptical? That's OK; but take it anyway; it asks you questions about yourself which are quite challenging, and thinking about your answers is an exercise worth doing.
You know what your strengths and weaknesses are; make sure you play to your strengths, but use the time wisely to push your boundaries and work on stuff which makes you uncomfortable: You may find that the effort pays off.
Share your information with your team, if you feel OK about it. It will help them get the best out of their relationship with you.
Your project needs certain fundamental roles to be fulfilled for the best chance of success. But note: the following are light-weight roles. The most important activity is working on the product!
Responsible for the team's relationship with the client. All communications with the client go through the Client Advocate.
The Client Advocate must understand the client's reasons for undertaking the project, and must represent them during any discussion.
The Client Advocate:
- Talks to the client. Main point of contact.
- Grasps an in-depth understanding of the requirements from the point of view of the client
- Works with the Tech Lead and User Advocate, to define the features of the product
- Advocates the client in any design decisions
- Regularly communicates with the client and ensures they know where the project is at all points.
- Ensures delivery
The Client gets deliveries through the Project Manager, and passes them to the Client. They are the last line of checking to make sure everything is OK!
Responsible for representing the interests of the end-users.
- Discusses, summarises and communicates the user-interface design to the team
- Grasps an in-depth understanding of the requirements from the point of view of the user
- Works with the Tech Lead and Client Advocate to define the features of the product
- Advocates the user in any design decisions
- Plans the tests to be performed on the product
- Organises and performs testing before release
- Collates and communicates live issues on the product to the rest of the team
Responsible for collating the technical information on the project, and disseminating it to the team.
The Tech Lead:
- Discusses, summarises and communicates the design with the rest of the team
- Grasps an in-depth understanding of the design, and the technologies to be used to implement it
- Reduces the design to a set of components
- Works with the project manager to build the tasklist (backlog) from the component design
- Advocates technical feasibility in any design decisions
- Collates and communicates technical solutions to the rest of the team
The information provided by the technical lead is essential in understanding how a product is to be designed and implemented with the time and resources available, with the lowest effort, lowest risk.
The Technical Lead is responsible for the construction and integrity of each delivery (does it contain the expected features, does it work).
Responsible for collating the status of the project, and disseminating it to the team:
The Project Manager:
- Records the effort available (budget) against the tasks to be done (backlog).
- Grasps an in-depth understanding of the progress of the project
- Works with the Tech Lead to create a task list(backlog) from the design.
- Advocates the budget in any design decisions
- Regularly canvases the team for their availability
- Schedules and communicates the tasks to be done, when, and who is assigned to them.
The information provided by the Project Manager is essential in understanding what needs to be done to complete the current sprint and the product as a whole.
The project manager is responsible for checking the delivery supplied by the Technical Lead, collating release notes, and passing on to the Client Advocate.
With small teams, everyone is responsible for testing and coding.
Here's some explanation of the activities you should be doing in the various phases of your project, to make sure you get a good result.
The requirements phases are important: this is where we can get an understanding of what you feel you can do over the project, and what you can deliver. Be frank about the effort you can put in, and realistic about the product that you think you'll get out.
The design phase is where you are confident you know what you want to deliver, and now want to make a plan. You can't make a plan without a basic design to work to; This is why we have a technical investigation running right from day one; to work out what is possible, and how long things take to do. Your technical investigation and your requirements should inform your design.
When you have a design, it's time to plan the Implementation phase; get an informed understanding of the effort it will take. Do this by breaking down your design into components, and working out the tasks it might take to create them. Assign effort (how many hours a developer would work on it until it is complete, including some testing) to each task. The implementation phase is 5 sprints (10 weeks) long. If your plan doesn't fit into this timescale, you may need to cut out some features, to make it fit.
Deliverables occur at the end of every sprint, right through the project. Make sure you deliver. It's a great thing to do; makes you feel good that you have something to show for your effort; makes the client feel good - it's progress; and it's evidence, for your portfolio. Where the deliverable is a document, make it sparse and clear. Don't waste time on formatting (Use markdown). We just want to know what you're doing and how we can help. It's the product which is important!
Finally, the release phase, is a time for tidying up, and making sure things are stable, before the big launch of your product.
Here are the phases in a bit more detail:
Object: Understand the problem and how a solution will be implemented.
This effort runs over 4 sprints, running in parallel with requirements capture. The whole team is involved.
This is an investigation of all the things needed to implement the project. How they will work, what pitfalls there might be.
Build up a good set of example code, links to resources, etc.
Deliverable: Evidence.
... in the form of source code and working demonstrations, backing the requirements capture.
Object: Understand the client's needs.
Start with nominating a Project Manager, Technical Lead, Client Advocate and User Advocate
Have a requirements meeting with your client.
Gather requirements from the client and feed into the technical investigation. Technical Lead, Client Advocate, User Advocate are responsible for interpreting the clients needs, and communicating them effectively.
Deliverable: Document. First draft Requirements. This document is based on the first bits of the technical investigation and focusses on what might be possible in the project.
Object: negotiate what is possible.
Use the technical investigation to figure out what will REALLY be possible in the implementation time available (5 sprints).
Have a second requirements meeting half-way through the sprint to comunicate with the client the technical findings, and negotiate the final requirements.
Write-up the requirements.
Deliverable: Document. The team's understanding of what the project will produce.
Provide a description of the product to be delivered:
- break the product down into features (wireframes / supporting documents as necessary)
- describe the beheviour of the product
- describe what technologies will be used.
Provide a first-guess estimate:
- how much effort (in developer-hours) it will take to do each feature.
- how much effort (in developer-hours) it will take to do the whole project. That's features plus testing, integration, and contingency for when stuff goes wrong.
- seperate the features into 'essential' and nice-to-have.
- define the minimum viable feature-set.
It's worth mentioning here, that the first-guess estimate is going to be very inaccurate - you need to go through the design phase to get one which is halfway usable. Your estimate becomes more acturate as you go through the project, and is 100% accurate on the last day :-)
Object: Produce an underlying design on which to develop the features.
We're looking for a really good understanding of the requirements, with a design and some proof that it can be done, informed by ongoing technical investigation.
Deliverable: Document. Initial Design.
Seperation of features into components and behaviors. Look where you can find commonalities (Don't Repeat Yourself).
Object: Produce a plan.
- Use the technical investigation to inform your refined design.
- Work out the tasks required to construct and integrate each one of the components into the product.
- Implicit in the task is repository / code maintenance and unit testing.
- Estimate how long each task should take in hours, by talking to the developers.
- Check that the tasks for the essential features fit into the Implementation time (5 sprints)
- Design compromises if the effort for the implementation of the features is too much.
Deliverable: Document.
- Refined design: Features, Components, Tasks.
- Project plan: scheduling of tasks into 5 sprints of effort.
- Proposal: Statement of the design and the effort needed, for the client to agree to, before moving on to construction.
Object: complete tasks, make a demo.
- Design, code, test, check-in. Repeat. Test the overall product.
- Communicate. Meet every day for 10 minutes to tell each other what you worked on, what you're going to work on, and what problems you had. BE KIND. Dont blame!
Deliverable:
- a product delivery.
- a revised plan. (NOTHING goes to plan! All you can do is revise your understanding and figure out what to do next)
At the end of sprint 9 development of new features is stopped. Concentrate now on release. Think about the release process, testing, tweeking, stability.
Made available for general testing
Final release for showcase.
Your project exists as a set of files in a code repository (our favourite is GitHub). When you make a delivery, your source code is deployed into the product, so that it can be used and tested by the Client.
You should try and make a delivery at the end of every sprint. If you get used to doing it, it will take half an hour.
At first it's going to look rubbish; but stay with it!
Make sure you produce a set of release notes to go with your delivery
- In your repository
- Linked to from an 'about' page
- contains:
- major bug fixes
- features implemented
Make sure your product can show the following to your users:
- a version number (. - e.g. 0.12)
- about - a link into an about page in your public repository, where you can show
- your names (if you want to)
- links to your portfolios (if you want to)
- attribution to any software you have used, which requires it.
- a link to your release notes
- license - we normally ask that any License is MIT.
We just mentioned communication in sprints, but we thought it so important, it's got a section to its-self.
Make sure you appoint roles to people, according to their strengths. Vote on it. Make sure everyone is aware of ther responsibilities as team members.
During the sprint phases, it's really important to organise who is doing what.
The best way of doing this we've found, so far, is to hold a 'stand-up' meeting at the start of every session you are together on the project.
During the design phases, you created a set of features for your project, and a design. You made a plan, and worked out what tasks were needed to build what components, and in what order.
The stand-up is where you review project progress, and assign tasks to people, to build that design.
The project manager organises the stand-up.
Each team member in-turn says what they did yesterday, what they intend to do today and any problems they are having.
If anyone is close to finishing a task, they can nominate themselves for the next task, or have one assigned by the rest of the team, via the project manager and technical lead.
The stand-up is short; the name comes from people standing-up to have the meeting (if your feet get tired, you've been there too long. Wrap it up!)
Most important: all communication with your client needs to be via your Client Advocate. That makes it easy :-)
If your client is DigitalLabs, use Alice as your point of contact. She is your gateway to DigitalLabs, for deliverables and support.
Thanks for reading. Good Luck!