GM on his role
I have overall responsibility for the development team.
So, it’s my job to ensure that the processes are clearly defined, the team understands what they’re supposed to be doing, and most importantly, that we’re delivering to the highest possible standard.
There’s other elements as well; like talking to existing clients about their requirements, making sure we’re going down the right route from an architectural viewpoint, and that the solutions we’re designing for them, satisfy their expectations and requirements.
Some days, the internal part of the job might mean I’m working closely with the project manager(s) and discussing the overall progress of a project, or, from a technical point of view, it might mean I’m translating some of the tech terms to a client or other members of the team.
GM on the project process
We like to have a presence in the early client meetings so that we can answer any of the problems or questions they have.
Roadmapping is a huge part of the initial stage because it provides us with an opportunity to say what is possible, what isn’t, discuss timeframes, and bring up any other factors, such as if the work the client is looking for could possibly exceed the budget they have in mind.
During the roadmapping phase we break down the bigger tasks into smaller ones and this is where you may see the use of some agile terminology. For example:
Epics
This is the body of work ( the project) that can be broken down into specific tasks called stories, and is based on the needs of the client.
Epics are helpful because it allows us to share work out into more manageable chunks, which when joined together, means large projects can be completed more easily and on time.
Stories
Quite simply, each story is a feature of the site and something that we have to build. I guess you could call it a to-do list.
Acceptance criteria
Acceptance criteria are the conditions the various stories must meet in order to be accepted by the user and/or client.GM on project prioritisation
We recently switched to the Kanban approach which is something I had experience of prior to my time at Creode.
Essentially, Kanban is a visual system for managing workflow as it moves through the project process, and it’s agile enough for us to scale up or down where appropriate.
What it allows developers to do is pick up a piece of work, focus on that piece of work until it’s finished and then stick it in the test environment/pass it onto the project manager, before moving on.
We find that this has been a great help when we’re working to tight deadlines.
It’s a really simple way and we don’t have people asking us what they should be doing now or next because it’s there electronically to see, or, on the job board in the office.
GM on the future of development
We might start to see that traditional content management systems become a thing of the past.
Many of the benefits have already been well documented, but I don’t think it’ll be long before we see more companies look at headless content management systems.
This will once again alter how content is presented, the type of content, and its frequency. It should see a shift towards a more app based way of digesting things, and the use of more static sites.
I think the big benefits will be its simplicity, speed and security. A static site is more or less “unhackable” when deployed to a serverless environment.
You'll be able to read more from Gareth next month, in the meantime, if you have a question get in touch with us today.
Proud to partner with
