For all of my professional career I have been associated with web development. From my early days starting as a junior developer, through to lead developer on projects, senior developer and now project management, I’ve learned some valuable lessons. From a developers viewpoint, and from a PM stance.

Being on both sides of the table, I can appreciate that project managers have deadlines, budgets, clients and stakeholders to please. Developers have clients (maybe not directly) and managers to please, but most importantly, developers have to be proud of what they are achieving, they have to (if you’ll pardon the phrase) “please themselves”  (this blog is so getting blacklisted in google)

For the past six months I’ve been in a new job, in a position I like to call “triple D”

Developers Designing Development

Triple D is a scenario that I’m all to familiar with in my career, whereby a developer is given a simple scope (normally verbally) and expected to expand and create what is required from very little substance. This of course leads to numerous iterations of code, and on-the-fly add ons to already untested or unstable code.

Stand up to them, just say no

Well sometimes that’s easier said than done. In my current situation I was fully aware of the scenario before taking on the work, knowing it’s just a short term situation whilst the bigger picture unfolds (and it’s unfolding and an epic rate!) I love my job, so this blog is in no way a reflection on my current position. But it is an observation of the way developers like to work, and ideal situations.

Previously, I have been in the position to say no, refusing to work without a signed off spec and guidelines as to exactly what I’m producing. However, this usually lead to *me* creating the documentation for *me* to work from. TRIPLE D!

It’s just a website

Well, it’s not really is it? I mean, fundamentally so, but the website is just the icing on the cake. Here is the cake recipe to hopefully avoid TRIPLE D ….

1. Requirements gathering session. This is just one big brain storming session. Sheets of paper, big marker pens and 20 minutes or so worth of ideas. You get the picture.
2. Reducing scope. Another 20 minutes sorting through the initial ideas. Categorising ideas into two groups, must and might, with further brainstorming for each must
3. We now have a list of  “musts”. These are now taken away and put into a high level spec, to give us a definite list of must have features that can be put to the stakeholders for sign off.
4. In Agile terms, each of these “musts” is effectively a “story”. Whilst not sticking to the rules of Scrum to-the-word, we take the foundations and make them work for us. Even more agile than agile! Each of these “musts” is added to our product backlog, and given a specification of its own.
5. The backlog is assessed, and split into smaller sections, as with scrum, referred to as “sprints”.  Each sprint is given a timescale. Work then begins on a sprint.
6. At the end of any given sprint, we assess what has been completed, and what hasn’t been completed is added to a backlog. Before the next sprint begins, we decide whether to adjust the sprint and add elements of the backlog to it, or continue and address the backlog at a later date (if not project critical)

And throughout the whole process, we have a progress chart to everyone involved can see what’s completed and whats remaining (again, as with Scrum, this is the same as a burn down chart, but in layman’s term).

Once all the sprints are completed, and the backlog addressed, we are left with a website (Sorry, no cake). And (hopefully), happy developers who feel proud and pleased with the work they have produced.

Developers should be allowed to develop, and given the required documentation to develop happily. The time and effort spent in creating such documentation will be far less than the time spent revisiting and repairing the work created if the documentation is overlooked.