Every project, and every client, is different. Different constraints, different objectives and different personalities mean that we can’t always fit a project into a process we decided on months or even years ago. Advances in technology, changes in working practices and attitudes mean that having a long-standing, pre-defined process isn’t practical in 2015.
Taking all those factors into account, we adapt our ‘process’ on a project-by-project basis, finding the best solution for us and for our clients.
While we don’t follow a strict process at Kind, our work roughly consists of 3 activities. For some clients these activities may need to be played out in full, following one another in a ‘waterfall’ process, but we’d advise against it.
Advocate’s of the agile methodology will spit when they hear about a waterfall process because it’s notorious for not allowing any wriggle-room when it comes to changes to the scope of the project.
We fully agree with that, but there are problems with every agile process we’ve tried too. While, our preferred way of working adopts a lot of the methodologies of the agile process, we choose not to adopt it fully. Oddly, we have found that ‘Agile’ is just too strict!
What we do use is the concept of working on the architecture, design and development of a project at the same time by splitting elements of the project into singular tasks. For instance, for a website project, rather than creating a ‘page’ we’ll build a navigation module, headers, paragraphs, the search module etc. all as separate jobs, each with their own architecture, design and development considerations and fully tested before being marked as complete.
When splitting a project into these tasks, we’ll work with the project owners (often our clients, but sometimes ourselves) to prioritise them, producing a Minimum Viable Product (MVP) - a group of tasks which constitutes the core of the project. Once we’ve completed all these MVP tasks, we’ll launch. After that we’ll reprioritise the remaining tasks, perhaps adding or removing some, and start the process again.
Regular communication with the project owners, allows us to give them full visibility of the project progress and demo what we’ve been working on since we last met. It also allows us to alter the MVP should something crop up that hadn’t been thought about before.
To somebody clued up on agile processes, this may sound like User Stories and Sprints, but we would beg to differ. We’ve found in the past that while User Stories are a good way of deciding on priorities, they often involve a lot of shoe-horning when it comes to those JFDI tasks. And while the word “Sprints” conjures up ideas of quick progress, we’ve found they often slow it down when reaching the business-end of a Sprint, people stop working on the task in hand, knowing it won’t be completed on time.
Having a smaller core process like this allows us to make those small tweaks or additions that work best for one particular project at one particular point in time.