Dezzy's weblog

I have recently just started developing a new iPhone app which I hope to complete by the time I go on my bike trip mid July. It amounts to about an hour work a day, but obviously I won’t be able to work on it everyday, especially during the week, but will be able to work on it more at weekends.

Motivation has been a real issue in starting work on this. A blog post went round work about motivation, and although we were not directly told to think about our own motivation because the developers at Softwire are all pretty determined (what with being very good from their university career). However I thought it would be a good idea, for the benefit of my Team Manager (TM) and future managers, to know what motivates me to get my work done. I found it as an opportunity to also address my individual motivation issue with not working on this project for months.

Copied from my weekly status email at Softwire:

Motivators:

To show people more of my products and creativity (i.e. show off)

To develop something for myself, alone without any help (i.e. be independent)

To develop game creating skills (because it is something I have enjoyed and would like to do more of)

 

Consequence:

To make some money

 

Demotivators:

Tired after work and don’t want to program after a long day of programming

“Better” things to do (e.g. socialising, working out, cycling, sleeping)

I have addressed the tired issue by just eating a lot more sugars, yes it is probably counter intuitive with respect to my lifestyle (e.g. exercising and eating well to stay fit) but by changing my lifestyle in this way I am really motivating myself to get on with this project. Don’t get me wrong, I still work out for 45 minutes every morning then cycle 30 minutes to work and then back at the end of the day, but I’m just pushing development of this game more.

I am going to use an agile wall to try to motivate me more as well. Having goals and the future planned out really helps to drive the determination to get things done so that: I know I can show people stuff if I get the following tasks done, I can see how much I have accomplished myself – independently and skillset wise, and a motivational push when I am nearly ready for release.

The columns are slightly adapted from conventional Agile walls since I am a team of one, there is no “Testing” column as such (because that should be covered when I’m implementing it – or I’m not very good at what I do for a living), but I do have some testing tasks that require me to set some friends up with profiles and let them get on with it and give me feedback about bugs and enjoyment.

On the far left I have release 2 stuff which are all features that would be cool to add, but only after releasing and getting most of the game working. Things in there currently are “Home screen with about, email, options etc” and “Leaderboards – local and global”. These tasks are yet to be fleshed out, but are put there so I don’t forget about fun and cool features that I would love to add in the future.

The next column is release 1 stuff. These are tasks that are essential before releasing the game, but they are not being worked on in the “Sprint” which is the next column. The “Sprint” involves tasks that I am working on over the coming week and they represent having a good piece of functionality that I could show people at the end of it. This initial sprint started at the beginning of this week and I am planning on getting it finished by the end of Sunday however it will be done when it is done, whether it is before or after since my life comes first! However it is good to have a goal to get a certain amount of work done by a certain time so I know I would be able to release by the time I go away on my bike trip.

—————-

As an aside I wanted to mention that I have been working with a team of 7 developers, a scrum master and PO at *censored company name* (one of Softwire’s clients) for almost 4 months now. We try to keep to the agile principles but throughout the process I have had problems with it and so have the team and so we continually try to change it to suit our work and environment. Therefore I really enjoy the retrospectives. I am adjusting my own processes for my own project here that try to prevent these problems.

At this corporate company, with a large development department, we try to keep to the agile principles by the book. This means not bringing in more work than we think we have hours for. Because we are in software and things *always* run over, we take 20% off our estimated amount of working time for the 2 week sprint to account for overheads, under estimation, bug fixes etc… so when we run out (which we do occasionally, we have to have another meeting to flesh out stories that probably haven’t changed from the end of the last sprint). This would be fine if our PO was easy to track down, but seeing as he regularly can’t attend our scheduled planning meeting this never happens so we end up scraping the barrel of low priority bug fixes and cleaning up the code-base from “technical debt”.

Regularly at the end of each sprint we might be half way through implementing a story (because with a team of 7 it is very hard to keep us all working and only work on one story and get it all completed and done) and so it gets carried over to the next sprint. Similarly we might be running out of work: so people will pick up tasks that they don’t want to do, or other people would be more suited to, or just picking up the tasks that are left on the board until the end of the sprint, probably because they are rubbish tasks that noone wants to do. Yes they are essential but it puts a downer on the end of a sprint, especially seeing as everything is normally completed by then and you are not adding any functionality, just polishing edges. I guess this is just a “feature” of agile, and be thankful there are smaller things every 2 weeks, as opposed to millions of things at the end of a huge release. If you can fix it now, you probably should right?

One of my overall pieces of personal motivation (that I am sure applies to a lot of developers) is that I like to create things to show people. Cleaning up code, or making a database call run faster is great to complete, but not as fun as adding in a new piece of demo-able functionality to the project. Perhaps this is why I am interested in creating a game! Although I imagine all of the other good software practices are applicable too.

—————-

With an individual project like this I can just work linearly on stories until they are complete and then move on to the next one. It means it would be great to get things done by the deadlines (which are mostly arbitrarily set) and if I go over I will just bring other things in and get ahead of next sprint. I have planned out everything I think I need for release one, so now I just need to do it. If I think of other things I need (as I would do because I am a team of 1) I will bring them in (as I did with a couple of small tasks to do with the UI that I had not thought about!).

So far I have only really worked on it for a couple of days as I have been getting to grips with the cocos2d libraries that I am going to be using.

This is an initial screen shot that doesn’t show much, other than I have some button images, life counters and scoreboard set up.

The game will become a lot clearer as it develops more, and like all things consumer based, will be a lot nicer with graphics! (Which is why I plan to work on some of these things this weekend so I can show people).

Here is a picture of my dev setup as well (a new mac book pro with a 24″ Dell secondary monitor), with the agile board behind on the large picture on the wall.