We don’t just code software. The company was founded by five like-minded computer scientists and engineers, passionate about innovating the entire software development process.
With nearly 80 years’ combined experience in development, our founders have witnessed enough poorly executed ventures and been involved in numerous hugely successful projects to have formed a clear vision of how projects should be run. We have a rigorous methodology for simplifying software development.
We use lightweight processes and well-known patterns which can evolve over time. We prefer to optimise for simplicity, speed, flexibility and evolution. Once these have been achieved, efficiency and cost saving will follow. Building high-quality software is a multi-dimensional discipline with many different factors to consider, which is why we always draw from best practice.
Our six dimensions methodology is the result of our lean and iterative development experience. Scrum or Kanban teams can use it as it can be implemented at the sprint or feature level.
Questions we ask: Do we have a clear understanding of the business and its needs? How can we use organisational structure and cultural values to reduce the friction between teams and build a high-trust environment?
• Define the high-level mission of the organisation. Trust people to do what is right.
• Encourage team autonomy and continuous improvement.
• Favour cross-functional teams that combine business and technology.
• Organise teams around business or product lines.
• Traditional business domains (sales, marketing, etc.) become cross-cutting concerns.
• Technical functions (architecture, QA, Ops, etc.) become cross-cutting concerns.
• Use communities of practice to manage these cross-cutting concerns.
Questions we ask: What are the end user’s needs? Where is the business going? Do we have clear, concise and easy to communicate requirements, allowing us to build structured delivery roadmaps?
• Use prototypes and experiments to validate ideas.
• Team autonomy can be enhanced by OKR.
• Use inception planning, story mapping and release planning to improve coordination and collaboration between teams.
• Use epics and user stories to decompose and structure team backlogs.
• Use BDD and Given/When/Then to define and deliver requirements.
• Use a common ubiquitous language to describe features, requirements and technical capabilities.
• Use structured group decision-making techniques when estimating.
Questions we ask: How do end users behave and what do they need? How can UI design solve their problems? What technologies will help us to control complexity?
• Use design thinking and customer journey engineering to improve UI design.
• Understand the different types of coupling which can occur in a software system.
• Software designs should be modular with clear separation between teams, domains and concerns.
• Target architecture establishes guidelines, implementation left to teams.
• Monoliths and micro-services have the same design considerations.
• Embrace plurality. A single DB technology, language or architectural style may not fit all use cases.
• Avoid path dependencies or an over-reliance on technologies and rigid processes.
• Security needs to be part of the design.
Questions we ask: Which development patterns and testing processes will work best on this project? Is the code clean and easy to understand? Is documentation sufficiently in-depth? Are we keeping it simple?
• Encourage software craftsmanship and continuous improvement at the team and individual level.
• Use extreme programming techniques to encourage high-quality software development.
• Use scrum and/or Kanban but focus on objectives and results rather than the process.
• Teams should be able to define their own processes, but they should also be flexible.
• Use TDD and BDD to improve the quality of deliverables.
Questions we ask: Do we have a pipeline that will deliver the software quickly? Have we automated processes where we can? Is the client involved in experimenting and learning with us?
• Use Continuous Integration and Continuous Deployment/Delivery
• Define tests in terms of scope (unit, component/module, service, system) and type (functional, integration, acceptance, performance and stress).
• Automate as much testing as possible.
• Speed up delivery by decoupling manual and exploratory testing from the production deployment pipeline.
• Avoid or reduce reliance on end-to-end or system-wide testing. Test services in isolation, use contract testing, decoupling deployment from release.
• Automate deployment all the way up to production.
• Teams should be able to deploy their software independently.
• Use infrastructure as code (IaC) to automate infrastructure provisioning.
Questions we ask: What should we measure for meaningful insights? Is there a process for measuring and understanding the impact of features or changes? Is monitoring and analytics in place?
• Consider metrics and monitoring at the beginning of a project, not the end.
• Aggregate logs for useful data and well as errors.
• Monitor infrastructure as well as applications.
• Teams should be responsible for monitoring the software (and infrastructure) they own.
• Define and capture business metrics, especially for key customer journeys.
• Incorporate health-checks into all services.
• Create data dashboards (a picture is worth a thousand words).
• Definition of Done defines how to verify a feature is working as intended.
Feel free to call us at +353 (0) 1482 6918 or use the form below to contact us 🙂
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
