Building Big — Make a Work Formula

Long Exposure Photo. Signal Hill Cape Town, Western Cape South Africa.

Part 2 in a series on Building Big 1, 2

So you have decided you are going to build big! And you have gone through creating a backlog to help you decide on which tasks to tackle and likely when.

Your project at this point should have a general ‘what’ and ‘why’.

Preparing your backlog will help you break down your huge project now to smaller chunks that may still be broken down.

When defining issues/tasks in your project backlog please remember they are emergent. An issue could reveal several more.

In fact I would go as far as saying most of creativity involves emergent issue discovery. As we envision value¹ that we would like to provide to the world we also find smaller sub-tasks that we would need to complete to go on. It’s more like an iceberg the more of it you see the bigger you realize it is.

Now while some of us could despair at this and see it as perpetual feature or problem discovering. This is where deciding what ‘done’ is helps with.

While you might be fine flying to the stars, You may be completely fine with landing on the moon for a start, then mars, then pluto …

Find your balance and you can break down your seemingly large project into smaller sub projects break those down further and you eventually have tasks that you can do today that are for your long term goals.

Making a Work Formula

The process detailed above and in the previous blog only leads you to discovery of action items that you need to tackle. Most of us I included are so revved up at this point that we just want to jump into the work!

But this may not be necessarily the best thing at this stage. Through trial and error I have found that defining how work will be done aids a huge deal in getting things done. At the end of the day isn’t this what we all want to do?

In order to decide on a work formula you need to decide on a number of things. Most of this would be covered in Sprint Planning if you are using agile² as a work methodology. If you have no idea what agile is we can outline the steps simply as follows.

Prerequisites

1. You have set up a taskboard³ that includes a workflow⁴ for your team.
2. You have roughly estimated some of the issues to be tacked.
3. You have agreed decide on a label guide ( this is crucial — the brain consumes image information 60,000 times faster than text. Deciding and agreeing on what images will mean what? Will help your team work on your project much easier and faster)

In order to start tackling our iceberg of a project we need to accept a few things.

Most of this will be a journey of discovery the more we do it the better we will likely get at it.

Your first few attempts at coherence will likely not be as smooth as you expect and this is because your team is still coming to facts with a number of factors. (New methods, New members maybe? , Confusion with the workflow, frustrations, real-world realities).

1. Refine your tasklist/backlog. By this I mean pick tasks and dissect them with your team state all the actions needed and how this will help with clarity in a huge way. It is recommended that you do this refinement as frequently as possible even daily if you can.
2. Decide on an sprint length. Decide how long everyone is going to be in work mode besides most of the work should be divided among the team members and deciding oh how long you guys will dive into work at a time will aid with estimation. Try and maintain the duration of work over a number of iterations that way you can always pick a number of tasks and finish them in a number of days. You get much better at this the more you do it.
3. As a team decide on which tasks you handle for this coming sprint. Let everyone weigh in and most importantly pick the most detailed tasks in your backlog/task list to tackle. These will likely be towards the top of the list as the more detailing a task gets the more it bubbles up in the order of the task list.

These three above would entail a huge amount of coming up with a work formula this will be unique for each team

Appendix

1. Value — What are you providing? product, service, market, industry. Make sure to have value definition to an end customer.
2. Agile — http://www.techrepublic.com/article/how-to-apply-agile-practices-with-your-non-tech-team-or-business/
3. Task board — A collection of all the tasks that have been discovered for a project and their status in the project at the moment.
4. Workflow — How and when to work. This includes diving the work up into the departments, Building feedback loops and deciding on product owners. These are individuals that are in charge of a product and know best about it.