Giving Up The Day Job
Tuesday, July 13. 2010
The In-A-Nutshell Version I have resigned from Ibuildings. I will complete my notice period here in a couple of weeks and then move on to a wide and interesting variety of well-paying freelance assignments covering development, consultancy, writing and speaking. Hopefully.
The slightly longer version really is this. Two and a half years ago, I left a job at a type of company I usually describe as a yet-another-website company, where literally every new project was another CMS website. Which was fun for about the first 4 months and got old pretty quickly. Two and a half years at Ibuildings and I haven't done yet-another-anything, the projects have been technical, challenging and my colleagues are the best qualified set of people I'll probably ever work with.
Along the way I've also done a wide variety of other things, most of which are achievements beyond my wildest dreams, some within the scope of this job and some on my own time but of course influenced by all that I've learned. I've delivered training, led projects, been published, become a regular conference speaker and travelled internationally doing so, collaborated on an open source project, edited a developer portal and hosted a major international PHP conference. I've even learned to say those things about myself in public without feeling too much of a fraud!
At this point, there are so many things I want to be doing, writing, speaking and so on, as well as some interesting development projects, that holding down my 9-5 as well has become untenable; that's the main motivation for this change. I don't intend to take another full time job, although I don't have a lot of paying work lined up so please bear in mind that I am looking for some ;)
Things I would like to be doing:
Advice on achieving any or all of the above is appreciated - if any of you can also think of me when discussing business, write me a linked in recommendation, or retweet my announcement of my news, that would be fabulous!!
If you're still reading, then I'll share a little something with you. I decided that with a career move, I needed a little rebrand, so here is my new angel avatar. I hope you like her :)
Wish me luck in my new (ad)venture, I'll be keeping everyone up to date as always!
The slightly longer version really is this. Two and a half years ago, I left a job at a type of company I usually describe as a yet-another-website company, where literally every new project was another CMS website. Which was fun for about the first 4 months and got old pretty quickly. Two and a half years at Ibuildings and I haven't done yet-another-anything, the projects have been technical, challenging and my colleagues are the best qualified set of people I'll probably ever work with.
Along the way I've also done a wide variety of other things, most of which are achievements beyond my wildest dreams, some within the scope of this job and some on my own time but of course influenced by all that I've learned. I've delivered training, led projects, been published, become a regular conference speaker and travelled internationally doing so, collaborated on an open source project, edited a developer portal and hosted a major international PHP conference. I've even learned to say those things about myself in public without feeling too much of a fraud!
At this point, there are so many things I want to be doing, writing, speaking and so on, as well as some interesting development projects, that holding down my 9-5 as well has become untenable; that's the main motivation for this change. I don't intend to take another full time job, although I don't have a lot of paying work lined up so please bear in mind that I am looking for some ;)
Things I would like to be doing:
- Working with development teams on skills, tools and process (think teach a man to fish, rather than sell him a fish)
- API development
- Technical writing
- Meeting cool and interesting people and embarking on cool and interesting projects together
Advice on achieving any or all of the above is appreciated - if any of you can also think of me when discussing business, write me a linked in recommendation, or retweet my announcement of my news, that would be fabulous!!
If you're still reading, then I'll share a little something with you. I decided that with a career move, I needed a little rebrand, so here is my new angel avatar. I hope you like her :)
Wish me luck in my new (ad)venture, I'll be keeping everyone up to date as always!
Burndown Charts
Tuesday, November 10. 2009
Disclaimer: I am not an expert on this topic and have never studied it formally. This is purely an explanation of how I've seen these charts used within Ibuildings and included in my talk Passing the Joel Test in the PHP World which triggered lots of questions and tweeting.
Burndown charts are a way of tracking how much work was estimated to be remaining at a given point in time, and we track this over time to give us some idea of the rate of change. We start with some estimates, then we track how much time is left at regular intervals, I do this daily, because its a sensible unit but there are no rules. Its much easier to show this rather than tell it so here is an example - we're making a dolls house.
(yes, this is a photo of me. This was my fourth birthday and the dolls house was a home-made gift from my parents - I still have it)
We need some numbers to start with, and I don't mean looking at a task and going "a week and a half ... ish?"! Tasks need to be in small enough increments that we can safely estimate them. By "safely" I mean realistically and hopefully accurately enough that you won't find your project manager following you to your car at night with a pitchfork in his hand. For our dolls house, the table looks something like this:
As you can see, we've got a large element listed in the middle of the table - 27 hours is too big to be a single estimate, so we'll break it down further.
The aim of this is to chart how the estimated outstanding work changes over time. So we start with the total estimates in place - I've added a week's worth of days, just because its easy to fit onto the page, but your chart might have dates rather than days and go on for longer. Each day copies the number of hours of the previous day as its initial value - we'll edit them when they change.
On Monday, all the work is still to be done, so we start with a chart that looks like this:
To make the chart is as simple as adding a "total" field to each of the day columns and turning that into a bar chart:
Let's say on Monday we get the first two tasks done - we set the "Monday" column for these tasks to zero because there is nothing outstanding. Now our table and chart look like this:
So each time some work is done which causes the estimated remaining work to be reduced, we update the figures in the table.
Imagine we're partway through and its Thursday, let's check in on our dolls house project:
At this point, its pretty obvious that the project isn't going well. The curve on the chart isn't steep enough to be able to reach zero by Friday and without having to interrogate developers (who of course are always 90% finished), we can see that overall, things aren't great. Project managers may know that there is one blocker which is causing the problem but if you didn't know ... then you do now :)
A closer look at the numbers against the tasks show that we started the reception rooms and the bathroom but neither are finished, the bedroom we've worked on for the last couple of days and its almost there ... you get the picture.
The ideal burndown chart tends towards zero at the point at which the project needs to be finished ... but working this way gives a nice graphical overview of whether thing are heading in that direction or not. Flat lines are generally the sign of something bad, and progress is really visible even when its spread across many tasks or many developers. The chart could have a column for who owns each task, and for extra points add an "actual" column so you can compare how the team performs against its estimates (this is "project velocity").
This post was really only intended to show things as I see and use them - if this helps you then great. If you want the "official" version then I can only suggest you get a book on scrum and find out how to do it from someone much more qualified than me :) If you're using this or something similar, then I'd love to hear how it works out for you and what you do differently - leave comments and tell me!
Burndown charts are a way of tracking how much work was estimated to be remaining at a given point in time, and we track this over time to give us some idea of the rate of change. We start with some estimates, then we track how much time is left at regular intervals, I do this daily, because its a sensible unit but there are no rules. Its much easier to show this rather than tell it so here is an example - we're making a dolls house.
(yes, this is a photo of me. This was my fourth birthday and the dolls house was a home-made gift from my parents - I still have it)
Task List and Estimates
We need some numbers to start with, and I don't mean looking at a task and going "a week and a half ... ish?"! Tasks need to be in small enough increments that we can safely estimate them. By "safely" I mean realistically and hopefully accurately enough that you won't find your project manager following you to your car at night with a pitchfork in his hand. For our dolls house, the table looks something like this:
| Task | Estimate |
| Assemble pre-built frame | 2 |
| Paint exterior | 2 |
| Paint windowframes | 1 |
| Decorate rooms | 27 |
| Fit carpets | 5 |
| Add furniture | 1 |
As you can see, we've got a large element listed in the middle of the table - 27 hours is too big to be a single estimate, so we'll break it down further.
| Task | Estimate |
| Assemble pre-built frame | 2 |
| Paint exterior | 2 |
| Paint windowframes | 1 |
| Decorate bedrooms | 8 |
| Decorate kitchen | 7 |
| Decorate bathroom | 5 |
| Decorate reception rooms | 7 |
| Fit carpets | 5 |
| Add furniture | 1 |
Charting Estimate Remaining Over Time
The aim of this is to chart how the estimated outstanding work changes over time. So we start with the total estimates in place - I've added a week's worth of days, just because its easy to fit onto the page, but your chart might have dates rather than days and go on for longer. Each day copies the number of hours of the previous day as its initial value - we'll edit them when they change.
On Monday, all the work is still to be done, so we start with a chart that looks like this:
| Task | Estimate | Mon | Tue | Wed | Thu | Fri |
| Assemble pre-built frame | 2 | 2 | 2 | 2 | 2 | 2 |
| Paint exterior | 2 | 2 | 2 | 2 | 2 | 2 |
| Paint windowframes | 1 | 1 | 1 | 1 | 1 | 1 |
| Decorate bedrooms | 8 | 8 | 8 | 8 | 8 | 8 |
| Decorate kitchen | 7 | 7 | 7 | 7 | 7 | 7 |
| Decorate bathroom | 5 | 5 | 5 | 5 | 5 | 5 |
| Decorate reception rooms | 7 | 7 | 7 | 7 | 7 | 7 |
| Fit carpets | 5 | 5 | 5 | 5 | 5 | 5 |
| Add furniture | 1 | 1 | 1 | 1 | 1 | 1 |
To make the chart is as simple as adding a "total" field to each of the day columns and turning that into a bar chart:
Let's say on Monday we get the first two tasks done - we set the "Monday" column for these tasks to zero because there is nothing outstanding. Now our table and chart look like this:
| Task | Estimate | Mon | Tue | Wed | Thu | Fri |
| Assemble pre-built frame | 2 | 0 | 0 | 0 | 0 | 0 |
| Paint exterior | 2 | 0 | 0 | 0 | 0 | 0 |
| Paint windowframes | 1 | 1 | 1 | 1 | 1 | 1 |
| Decorate bedrooms | 8 | 8 | 8 | 8 | 8 | 8 |
| Decorate kitchen | 7 | 7 | 7 | 7 | 7 | 7 |
| Decorate bathroom | 5 | 5 | 5 | 5 | 5 | 5 |
| Decorate reception rooms | 7 | 7 | 7 | 7 | 7 | 7 |
| Fit carpets | 5 | 5 | 5 | 5 | 5 | 5 |
| Add furniture | 1 | 1 | 1 | 1 | 1 | 1 |
So each time some work is done which causes the estimated remaining work to be reduced, we update the figures in the table.
During the Main Phase
Imagine we're partway through and its Thursday, let's check in on our dolls house project:
| Task | Estimate | Mon | Tue | Wed | Thu | Fri |
| Assemble pre-built frame | 2 | 0 | 0 | 0 | 0 | 0 |
| Paint exterior | 2 | 0 | 0 | 0 | 0 | 0 |
| Paint windowframes | 1 | 1 | 1 | 1 | 1 | 1 |
| Decorate bedrooms | 8 | 8 | 8 | 6 | 1 | 1 |
| Decorate kitchen | 7 | 7 | 7 | 7 | 7 | 7 |
| Decorate bathroom | 5 | 5 | 5 | 5 | 2 | 2 |
| Decorate reception rooms | 7 | 7 | 3 | 3 | 3 | 3 |
| Fit carpets | 5 | 5 | 5 | 5 | 5 | 5 |
| Add furniture | 1 | 1 | 1 | 1 | 1 | 1 |
At this point, its pretty obvious that the project isn't going well. The curve on the chart isn't steep enough to be able to reach zero by Friday and without having to interrogate developers (who of course are always 90% finished), we can see that overall, things aren't great. Project managers may know that there is one blocker which is causing the problem but if you didn't know ... then you do now :)
A closer look at the numbers against the tasks show that we started the reception rooms and the bathroom but neither are finished, the bedroom we've worked on for the last couple of days and its almost there ... you get the picture.
The Aim of the Game
The ideal burndown chart tends towards zero at the point at which the project needs to be finished ... but working this way gives a nice graphical overview of whether thing are heading in that direction or not. Flat lines are generally the sign of something bad, and progress is really visible even when its spread across many tasks or many developers. The chart could have a column for who owns each task, and for extra points add an "actual" column so you can compare how the team performs against its estimates (this is "project velocity").
This post was really only intended to show things as I see and use them - if this helps you then great. If you want the "official" version then I can only suggest you get a book on scrum and find out how to do it from someone much more qualified than me :) If you're using this or something similar, then I'd love to hear how it works out for you and what you do differently - leave comments and tell me!
Announcement: Editor-in-Chief of Ibuildings Techportal
Wednesday, November 4. 2009
Working at The Hub, Bristol
Monday, September 28. 2009
A Bit About Burnout
Wednesday, August 19. 2009
Preparing to Telecommute
Saturday, February 9. 2008
On Monday I start my new job and I'll be mostly working from home which will be nice, but quite a change. I have a lot of online friends that I have yet to meet in real life but to have a whole set of colleagues, some of them in another country (IBuildings is a Dutch company) is all new to me. It'll be nice to avoid the annoyances of sharing an office, with other people's music and cleaning up after others too. I know I am organised and self-motivated enough to manage the working patterns as well, which is one less thing to worry about. If I had needed to be in the office every day, I simply couldn't have managed it as they are based in London. In preparation for next week, I thought I'd share some photos of my home office. To the left are my flower pictures that I found in a box when we moved, they came from another house we previously rented.I also have some essential accessories for any office: A map of the world and a nabaztag. This one is called Tag and is our second one of these rabbits.
Finally, check out my lovely big office chair, modelled here by my Christmas bear, now named Busibear as he lives in the office and oversees business. The chair was a birthday present from my parents, thanks mum and dad :)
I have a nice new notebook and a futon for any visitors that pop in, I think I'm all set...
Comments