If you are starting a new technology venture as a non-technical founder or as a business leader within an enterprise, one of the most challenging aspects is finding a reliable technical leader who can support your long-term vision and help you succeed. Finding a technical partner is one of the most difficult but impactful decisions you can make. Rather than rush into a decision, it is common for business leaders to adopt a long-term, strategic approach, using a partner like fourTheorem as their “fractional CTO” and engineering team until they are ready to grow the engineering side of the business internally. This applies equally to innovation teams in larger enterprises.
Customers are reassured by this approach for several reasons:
- Our founders and team have been through multiple startups, both funded and bootstrapped, so we understand what it takes to succeed in a startup environment and are obsessed with making every dollar of investment count.
- We don’t overload the team with hourly billable engineers. By keeping the team size small, communication overhead is minimised and the speed of innovation is maximised.
- We are deeply technical but understand that business value is critical. If we are asked to do something that we don’t feel will move the needle for agreed, important metrics, we will push back.
- We do our work with transparency. We work collaboratively with customers, not just for them, so we are in constant communication and share the highs and the lows. Nobody likes surprises when it comes to the success of their project.
If you haven’t been deep in the weeds with software development projects, you might be unsure about how the process works. It’s not unusual to expect that it will work like other projects outside the software industry. This is definitely not the case and you might even get a bit of culture shock when you get into your first proper software engineering project. To prepare potential clients for this, we wanted to describe our methodology and way of working. By the end of this article, we hope you know what to expect and are reassured that we know what it takes to achieve success for your venture.
Before we commit
We can bring value to you and your project, even before you have to put your hands in your pocket. You might first meet us at one of the industry or tech events we speak at, or get introduced by one of our existing customers or a partner like AWS. Like everyone else in the business, we’ll briefly try to wow you with our sales deck, tech credentials and previous successes! Unlike everyone else, we’ll be curious to understand your problem in detail from the start and want to start picturing what a journey to success looks like.
This might involve our lead architects sitting with the right people in your team for half a day to dive deep into the business and technical challenges. Once this is complete, you get one of two outcomes. The first possible outcome is that we agree that we have a good fit and give you a proposal to bring your project to reality. Alternatively, we might agree that fourTheorem is not the best option for you at this time. Either way, everyone who has taken part in this pre-commitment phase with us finds that it has delivered value and brought their business one step further.
Why are software projects different?
Before we get into the details of our process, it’s worth sharing a few words about why software projects are different to those in other industries. Relative to other engineering disciplines, software is a very new field, with only about 70 years of history. In that time, practitioners have struggled with basic concepts like scope, timelines, budget and quality, largely because there is a temptation to treat them like any other discipline. What is it that’s so different about software?
Increased complexity
Software systems usually have many more variables than physical engineering systems. To illustrate this, let’s compare the example of designing and building an electric coffee grinder to a mobile website! Unlike a mobile website or app, the coffee grinder is an example of a traditional engineering effort that has more fixed constraints and inputs.
| ☕ Engineering a Coffee Grinder | 📱Building a Mobile Website |
|---|---|
| Clear Specifications: A coffee grinder is designed with a specific set of functions – grinding coffee to various sizes. The requirements are clear and usually don't change once the design is finalised. | Dynamic Requirements: A mobile website needs to adapt to a variety of user needs and expectations, which can change rapidly. Unlike the coffee grinder, you might need to update the website frequently to meet new user demands or to stay ahead of competitors. The process of understanding requirements, communicating them clearly and making them a reality in working software, is complex and one of the seemingly simple steps that cause great project ideas to falter. |
| Controlled Environment: It operates under predictable and controlled conditions – usually in a kitchen with a stable power supply. | Diverse Operating Conditions: The website must function across different devices (smartphones, tablets), operating systems, and browsers, each with its own specifications and continuous updates. This diversity is much broader than the stable, predictable environment of a kitchen. |
| Limited Interaction: The user interaction with a coffee grinder is straightforward and limited. There are only a few ways to use it, and these don't change over time. | Complex User Interaction: User interaction with a website is complex and varied. Different users might use the website in ways you didn’t anticipate. This could be something as trivial as entering a special character in the “First Name” field of your signup form, or it could be something more nefarious, like a malicious actor using a new hacking technique to try and access your customer data and launch a ransomware attack. |
| Predictable Outcomes: The outcomes of a coffee grinder are predictable. If you put coffee beans in, you get ground coffee out, and the process doesn't vary much. | Variable Outcomes: The output of a mobile website is not as predictable as a coffee grinder. Network issues, user errors, or software bugs can all lead to unexpected results. We will use automated quality control including testing and deployment, but software bugs are inevitable and require ongoing maintenance. |
| Physical Constraints: Its design and functionality are constrained by physical materials and laws of physics, which are well-understood and stable over time. | Evolving Technologies: Software engineering is guided by ever-evolving technologies and practices. What's cutting-edge today might be obsolete in a few years, unlike the relatively stable principles of mechanical engineering used in making a coffee grinder. Except for rare cases, it’s not possible to build a software system and leave it in place without ongoing work. Systems need regular updates to ensure they stay secure to keep up with hackers and make sure that they still work with the latest hardware. As such, software projects are never really “complete”. |
Even for seemingly straightforward projects, software has much more complexity and requires skill combined with experience. You need a high-performing team of domain experts and software engineers, working together to take business and user feedback, distil it into prioritised tasks and predictably deliver on those tasks. Not every organisation has the know-how and culture to create these teams. Many consultancy practices use complexity and unpredictability to their commercial advantage, adding more staff and letting timelines go over.
How are Software Projects managed?
In an ideal world, any project would have a simple sequence of phases.
- Specification
- Analysis
- Design
- Implementation
- Test
- Release
In fact, these phases of software development were conceived as far back as the 1950s, described in a seminal 1970 paper by Winston Royce, later named the“Waterfall Model”, after the tumbling visual representation of the phases described.
The industry loved this diagram so much that the methodology was adopted en masse, ignoring the subtleties and the specific context the paper was written in. Such a methodology is simply too rigid, based on the assumption that all requirements for a system can be known and stated clearly in advance. It doesn’t allow for iterative learning and course correction.
Over the next 30 years, breakthroughs and influences like Extreme Programming and Lean Manufacturing led to the rise of Agile Software Development. The shift from up-front planning and rigid project plans to early, continuous delivery of small iterations had a massive impact. Done right, this new way of working delivers less waste, higher quality systems, more satisfied teams, and, ultimately, happier customers.
As with any methodology or principles, doing it right isn’t straightforward and Agile Software Development often gets a bad name when it goes wrong. Discipline is still required to ensure you gather product requirements regularly and effectively, automate deployment, test everything well, and keep delivering small, useful units all the time. You also need to have metrics in place to collectively measure how well the agile process is performing and a way to understand how to make improvement happen.
All of this means that you need to be prepared for continuous improvement, flexibility and a “whole team” approach to delivering on the project’s success. Good engineering alone is not enough. Iterative, continuous deployment and improvement needs regular, open communication.
Software Development is not just Coding
Depending on the study you pick, you’ll find that developers spend between 1 and 4 hours out of a typical 8-hour working day on coding. If this seems like low productivity to you, it’s worth considering what the actual functions of a software developer are. There is a lot more to it than programming.
- Understanding the customer/business needs
- Learning the right tools to do the job to ensure the optimum approach. No matter how experienced the developer is, learning is a daily part of the job.
- Analysing bugs and constraints in existing systems, often systems that were implemented by others who aren’t available anymore
- Sharing updates with stakeholders
- Sharing learnings and ideas with peers
- Collaborating with QA staff, UX/UI designers, project managers and others
- Creating, reviewing and updating documentation
- Peer-reviewing code
- Writing and rewriting code, tests, infrastructure
Getting the balance right between focused implementation time and collaborative, communication time, is a key factor in productivity. Too many meetings and interruptions can kill momentum. Too little communication can lead to misunderstandings, rework and swathes of wasted effort. The amount of code produced cannot be used as a measure of productivity. That mistake can lead to over-engineering and the creation of large amounts of technical debt. Every line of code written is a line that has to be maintained bug-free into the future. Technical debt emerges when you accept any kind of technical shortcut in the implementation today in order to get something done quicker, or to get it done without waiting for some external dependency. Some degree of debt is acceptable, but if you accumulate it without paying it off, you will eventually become technically bankrupt!
An expert group of software engineers will produce excellent outputs if the environment and the inputs to the team are optimised for success. If they are separated from the rest of the business and treated as a factory where requirements go in and features come out, failure is inevitable.
Effective software development comes from having:
- Skilled engineers and domain experts
- A whole-team approach, with business and technical stakeholders working together
- Clear mission and success criteria
- Requirements broken down into small pieces that can be delivered in fast iterations
- Clear communication and feedback mechanisms with no gatekeeping between the customer and those tasked with delivering the product
Permission to fail, learn and improve
Agile projects are often organised into sprints – periods of 1-4 weeks that are defined planning and feedback cycles. By planning what you intend to work on for the duration of a sprint, you can focus on a limited set of features, avoid disruption by minimising mid-sprint scope changes, and ensure that the time to get feedback from users and stakeholders is never longer than a few weeks.
Getting started - Sprint Zero
A lot of preparation is required before you begin. While many teams just incorporate this into the first normal sprint, a special preparatory sprint called “Sprint Zero” is often used to lay the foundations before the normal development cycle begins. At fourTheorem, our typical projects begin with a one-week Sprint Zero followed by two-week sprints.
Sprint Zero comprises an intensive in-person workshop followed by documentation and delivery of the outputs. Let’s go through the important considerations for this week’s work.
- The workshop is attended full-time by the project stakeholder, customer domain experts, architects, developers and UX/UI expert(s).
- The mission and objectives for the project are mutually agreed.
- The product backlog – a prioritised list of features is written and clarified with all present.
- If applicable, any relevant existing/legacy systems are analysed and documented.
- The initial target architecture (system design) is drawn at high-level (logical) and detailed (physical) levels. This establishes the technical vision for the engineering team. User interface wireframes may be introduced or drafted at this stage if relevant.
- Business and technical KPIs are agreed.
- Risks, actions and dependencies are identified and logged so they can be resolved/mitigated as a priority.
- The backlog is estimated using high-level “T-Shirt Size” estimates.
- This is used to extrapolate an indicative timeline with phasing for the release of features. It also allows us to calculate an estimate of the cost to achieve key milestones in the project lifecycle.
Sprint Zero Overview
At the end of the week, we are ready to enter the regular sprint cadence with working software as the output.
Understanding the Development Process
Directly following Sprint Zero, the first proper sprint establishes the cadence. The main activity within regular sprints is delivery of prioritised features and tasks including continuous deployment to your production environment. This is the part that requires programming and the creation of virtual infrastructure in a cloud environment. Waiting until the end of a sprint (or later!) to deploy software has been shown to slow down high-performing teams so we follow the best practice of continuous delivery. Once good planning is in place, backlog items ideally take between 0.5 and 3 days to deliver. There will be unexpected hitches along the way, external blockers will happen, and sometimes developers will end up spending a day or so resolving an unanticipated issue. By breaking work down into shorter tasks, the overall impact on the estimated schedule is lessened.
Two-week sprints involve a few regular meetings with specific goals.
- A planning meeting with the product owner and the delivery team takes place at the start of every sprint. This reviews the top of the backlog, checks priorities, adjusts based on feedback and ensures that prioritised items are understood, well defined and have any dependencies fulfilled.
- Daily stand-up meetings happen each morning with the delivery team. This allows the team to raise and tackle any blockers, review work done and self-organise for the day ahead. It does not take more than 10-15 minutes.
- Weekly demos are open to all client stakeholders and interested parties. Here, we showcase working software and identify wins and any failings or areas for improvement. This is crucial to getting feedback, building trust, and ensuring we are on the right path.
The end of the sprint review measures progress with the KPIs, project checklist and risk/action log. - The delivery team retrospective identifies what went well and not well, highlighting areas for improvement.
The value in the time spent during these meetings is constantly under review to make sure they don’t descend into a waste of time. Engineers will reach out to product stakeholders regularly to seek clarification too.
Milestones and Releases
Although the process is continuous, you will still be focused on milestones – checkpoints in the process that enable you to secure new customers, kick-off marketing campaigns, or secure funding. When creating a new platform from scratch, we aim to have a working, valuable MVP in production in 6-8 weeks. This first milestone gives you an early chance to evaluate our partnership and decide how to proceed. For some of our customers, this leads to a continued, long-lived collaboration. In other cases, we can help you to transition development to your own, growing engineering team.
Summary
In this article, we covered the main principles of our approach to software projects:
- Finding a trusted partner for the crucial initial period before you build out your own engineering function is daunting.
- Our experience as startup founders means we understand this challenge and ensure we don’t waste founders’ time or money.
- Software development is inherently more complex than other industries and requires an agile approach with the right balance of rigour and adaptability.
- Measurement of key metrics and a process for continuous improvement is essential.
- We provide initial value as part of our discovery meetings before you need to commit to a statement of work.
- Our Sprint Zero process provides a focused activity for all participants to set your project up for maximum success.
- We ensure continuous delivery to a working production environment to quickly gather feedback from your users and stakeholders.
- A regular development cadence with focused, collaborative meetings gives everyone a regular chance to align and incorporate feedback.
Our approach to building software doesn’t compromise on the satisfaction our people get from their work or the outcome for our customers. It is possible to achieve both and to avoid the kind of panic, overwork, and stress that lead projects into chaos. For established customers with their own processes, we will align and find a way of collaborating that works for everyone. Whether we are working with a brand-new startup or a large, established enterprise, we find something that works, and if anything is off, we’ll call it out, fix it and move forward. If this all sounds like a fit for you, let us know. We would love to hear from you.
References
- Majority of developers spending half, or less, of their day coding, report finds – TechRepublic – https://www.techrepublic.com/article/majority-of-developers-spending-half-or-less-of-their-day-coding-report-finds/
- 2023 software.com Future of Work Report – https://www.software.com/reports/future-of-work
- Managing the Development of Large Software Systems, Dr. WInston W. Royce, 1970 – https://www.praxisframework.org/files/royce1970.pdf
