At Full Fat Things we’re proud of the flexible approach we take to designing software — and to working with our customers. Much of this is described elsewhere on our website, but we had more to share on the subject, so we thought we’d expand it into this blog post.
How we get started
The first thing we’ll do is talk to you about your goals for the project, just as any good agency would. What are your desired outcomes? And what are your key performance indicators?
It's important to us to check our proposals are really likely to meet your goals. We do this before we start any development, rather than just making suggestions to match whatever is in your brief. To that end, we aim to identify things you may not have thought about and spot opportunities you’ve missed.
We believe we’re most effective when we work as part of your team, so we arrange our processes with that in mind – but ensuring we can still be agile and work at speed. So we’ll also ask you more wide-reaching questions about your organisation, your staff and how you like to work.
Ultimately, your experience during the development process should be as good as when using the final product. We keep that front of mind from day one.
Unique applications need bespoke design
When we agreed that I’d write this blog post, there was some debate among the team about the real meaning of ‘bespoke software design’. Ultimately, very few software applications are completely bespoke as they'll use established platforms and software modules as a base, and may draw on other successful applications in places.
However, every application we build is unique, even if it's similar to others we’ve built previously. And the design process we follow will always be bespoke for each client, because no two clients – or their existing setups – will be identical.
When we approach building your software, we’ll look at all of your relevant business systems, such as sales, customer relationship management (CRM) and enterprise resource planning (ERP) systems. Then we’ll check any workflows and connections (or borders) between them and compare this with how data needs to flow in future. Only once we’ve done that can we properly figure out what we need to do to connect everything in a way that provides a seamless experience for your team and your customers.
Agile, Scrum and good governance
When we work in an iterative manner, we use Agile software development and Scrum practices, and follow lean principles using short sprints of two to four weeks. This enables us to focus on delivering iteratively and to a high quality, and to set valuable features live as soon and as often as possible.
However, we don’t believe that the default Scrum and Agile operations offer the right level of governance to ensure projects are delivered on time and on budget. We therefore add layers of cost control and transparency to our processes. These let us – and you – monitor the budget and match it against a project’s progress. We think it’s important that everyone is clear at all times how far we are through a project in terms of both budget and the features that have been delivered, and that are still outstanding.
Keeping you informed
Communication is essential throughout a project. Every project is different, so we adopt whichever combination of communications will work best for you and the project. These may include standup meetings, ‘Three Amigos sessions’ and ‘backlog (or roadmap) reviews’. These are all ways we track progress, make decisions and quickly move forward.
(If you aren’t familiar with Agile working, our use of the term ‘backlog’ might concern you. However, ‘backlog items’ aren’t behind schedule. Instead, they simply haven’t been scheduled yet – more of a back log than a backlog. Backlog items are usually prioritised against each other, so that when we schedule the next batch of work, we take from the top of the backlog. We’ll get you involved in prioritising backlog items as you will naturally understand which are the most important parts of your product to build first.)
We also encourage you to get in touch with us whenever you want. That’s one of the benefits of adopting us as part of your team.
Development and delivery cycles
Our development cycles differ for each project and are determined by our early work together.
In the end, everything we do for every customer revolves around detailed planning, delivery of those plans and demonstrating what we’ve built…. And then we start all over again. The rigour of following one pattern is both flexible for you and shows the value we’re delivering throughout a project.
As I mentioned earlier, we’re happy to revise deliverables and schedules. This is part of the value of delivering in an iterative fashion. You get to control your project on a weekly basis and move the goalposts as we collectively learn more.
This level of flexibility not only keeps existing customers happy but helps us attract new ones. It’s not unusual for us to find we’re working for both the previous and new employers of our primary sponsors when they leave one business and move to another.
You can find more details about our development and delivery cycle in the page describing our approach to application development.