In a previous post, I talked about why I don’t do fixed-time, fixed-price projects. In this post, I’ll talk about an alternative workflow that I’ve developed over the last few years. It has, so far, been effective for teams of 2-12, and can be implemented by absolutely anyone.
First, let’s define what we’re trying to accomplish.
The Goal: to make good software quickly
…that’s it! It might sound simple, but at the beginning of the project, you have to define what “good software” means. In most of my current engagements, “good software” means software that accomplishes business goals, but if the software isn’t for a business, you may have a different definition. No matter, this process will still work for you.
The Workflow
As you can see, the process isn’t complicated; only 3 phases, which we’ll talk about in detail below. It’s an iterative process: once you get to the end, you go back to the beginning.
The important thing to note is the timeline – a maximum of 1 week per iteration. Why one week? Mainly because of the feedback phase; getting feedback every week ensures focus and strengthens the bond between business requirements and production. Nothing is more frustrating than a misunderstanding that doesn’t get caught for months and leads to a ton of unnecessary work.
Phase 1: Priority Meeting
Goal: to get everyone on the same page about the work for the week
Output: a prioritized (ordered) list of work items
The priority meeting is where you review the work done last week and agree on the work to be done for the next week. It’s also an opportunity to get everyone on the team on the same page, and re-focus the team on the overall team goals outside of their sphere of influence.
The main output for this phase is the prioritized list of work items. This can take any form you want, from a spreadsheet to your favourite project management tool (I use Asana). The important part is that you have the following information for each work item:
- the priority of the work item (aka the order)
- the person the work item is assigned to (the assignee)
- a description of what the outputs of the work items are (I call these acceptance criteria)
- any information that the assignee will need to complete the work item
- (optional) the status of the work item
The prioritized list should be available for everyone on the team to view, as it’s how each team member knows what to work on next. Because the list is ordered, any team member can simply start at the top of the list, and find the next work item that has their name on it.
A note on priorities: no two work items can share the same priority. Priorities are discreet and unique.
A note on work items: no work item should contain more work than can be completed in a week. Ideally, each work item should contain only enough work for 2-3 days. If you have work items that you think will take longer than a week, then you can simply split the task up into smaller pieces.
I like to ensure that the priority meeting takes no longer than 1 hour. For bigger teams, you may need to have multiple meetings based on types of production (i.e. high-level priority meeting for managers, priority meetings for individual teams of design, coding, marketing, etc)
Phase 2: Production
Goal: to complete the work for the week
Outputs: production artifacts (i.e. code, design files, marketing plans, etc)
The production phase is the real meat of the process, and usually takes 2-4 days. This is where all of the coding, design, research, marketing, sales, etc gets done.
There’s not much to say about this phase except that it should be directed by the prioritized list from the previous phase. Work items should be completed in priority order, and should only be considered complete when the acceptance criteria that are notes in each task are met.
Phase 3: Feedback
Goal: to ensure the quality of the work done during the previous phase
Output: a list of revisions to make for each task in the prioritized list
Feedback is often neglected in many organizations, but it’s absolutely vital. Not only does it ensure the correctness of the work that was done, but it also allows you to train team members to conform to your organizations standards. It’s a huge opportunity, so don’t waste it. Take the time to do it right.
Everything can be given feedback, and feedback should be given by everyone. Obviously reviews should be given for code and designs and user testing should be done for prototypes, but people often forget that even things like business and marketing plans, pitches and customer communications can be reviewed. For example: if the CEO is working on a pitch, the best way to ensure it’s understandable and convincing is to pitch the team, and see if they are convinced.
The value of feedback is immense. It’s easy to think that you made something high-quality after looking at it yourself for 2-4 days. The real test of whether or not you created a quality output is if others confirm your bias.
The outputs are a list of revisions. Keep in mind that after the revisions are made, they will also need to be reviewed before the task can be closed, so it might be best to add the revisions as work items in the next week’s priority meeting if they are extensive.
Make it your own!
What works for one organization may not work for another. I’ve kept this workflow intentionally vague; free of specific tools, so that you can mould it to your own team. Every time I set up this process for a new team, I take into account the team’s unique situation, and make changes as I see fit.
Remember the goal: to make good software quickly. If you find a way to make your software better or faster by tweaking the process, then go for it! If you find it works, I’d love to hear from you. Leave a comment or drop me a line on twitter.