Steve Mactaggart | 
10 3rd, 2011| 
So I started thinking that I needed to find something to focus my writing on, I spend talking about solutions to lots of different problems, but unless you are heavy into ERP systems, Accounting Journals or Costing Methods you’d probably get bored very quickly.
But that’s not all I work at, you see I AM currently working for a company that’s building an ERP solution, but thats the what, not the how. Â And I think its the how that is much more interesting.
I want to try and start to write about how we do the software development, and when I started thinking about where to start I looked at some of the biggest questions we are still yet to understand. Â You see I’ve been a developer for 13+ years now, and its only recently that I’ve been with a company where the development team is larger than 2.
Most places I’ve worked it’s be me and someone else, and we just battle through to get the work done as fast and as good as we could do, and anything we missed, we went back and fixed, and anything that didn’t work, we worked out and then fixed, and anything that wasn’t asked for (but needed) we would work out and do.
Not a lot of process, and even less structure.
I can’t say the current team is much larger, but its getting there. Â Currently 5 in the development team, a few more when you rope in the User Experiance and Design staff.
If things go the right way we’ll have even more soon, so I know I’m rambling, but what I’m getting to is process. Â I don’t have a really solid, tried and tested process that extends well beyond a 2-3 man team, and we need one.
So I’m going to try and use my blog as a place to pose some questions and issues we have with software development, take some time to discuss the solutions we have proposed, and review research by others online.
We currently use a “sort of” Scrum process, we hide behind things like, “we write stories not specs”, and “things need to be small enough to fit into the sprint”, but I keep feeling that we really don’t “get it”… Â I want to try and take some time to do some research into a Scrum process, and try and hash out how we can make it work within the four walls of our office.
So that’s the plan, over the next few weeks I’m going to try and write about one aspect of our current process, or a general software development area, and try and see how different solutions may solve the problem.
But what does this all have to do with Blue Rocks you say, (the title of the post… look up the top there if you missed it).
We have a story in the office about writing specs, we all come from processes where the specs were very sparse, and we all have our own way of filling in the gaps. This is becoming a major failing in our process.
The “Blue Rocks” referes to a question often thrown around as an example to highlight how vague a requirement is. “If we all had to go and get a blue rock, and I bet we would all come back with something different”. So my first task is to do a bit more research into the Scrum process of defining Stories, what make good stories, what types don’t work, and how do we all write better ones.