September 15, 2023
Improving your software development process Part 2: Agile
Written By
Alex Harvey
Category
Agile
Tips
Read time
10+ minute
Introduction
In a previous blog post, we looked at how we can create a more efficient and effective software development team and provide greater value to customers through lean software development, a methodology that achieves these things by empowering employees to identify and eliminate waste.
In today’s blog post, we’ll be looking at agile software development, which emphasises the importance of communication, continuous delivery, feedback and flexibility for a successful project. This is crucial for startups as they have limited resources and often need to adjust their business model or product offerings as they learn more about their customers and find their product-market fit. Without constant and recurring feedback, startups lose the ability to pivot quickly and steer in the right direction, which can ultimately lead to their demise.
It’s also important for enterprise businesses to be agile, as it encourages experimentation and risk-taking while also delivering features to customers in a timely manner. This allows them to stay innovative in competitive markets and deliver high-quality software that meets the needs of their customers and ultimately helps drive growth and success. A good example of this is Monzo, who used feedback from small businesses to drive the feature development of their business banking accounts - "Over the past few weeks, we’ve spent lots of time talking to small business owners, reading your comments on the community forum, and understanding what you expect from a business account” (more info here). Another example is Spotify, who’ve taken agile software development to a new level, as outlined in their paper Scaling Agile @ Spotify.
Undergoing a digital transformation to make your company more agile can save your business time and money, helping you make data-driven decisions and ultimately achieve your goals faster. Lean and agile form the foundations of what we do at Contic, so if you need help transforming your business, feel free to get in touch!
Agile
The first thing to note about agile is that it isn’t a rigid set of specific development techniques. It is instead a set of guidelines that prioritise streamlined communication, continuous delivery, regular feedback and flexibility. The Agile Manifesto sets out 12 principles that make up agile software development:
-
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
-
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
-
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
-
Business people and developers must work together daily throughout the project.
-
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
-
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
-
Working software is the primary measure of progress.
-
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
-
Continuous attention to technical excellence and good design enhances agility.
-
Simplicity--the art of maximizing the amount of work not done--is essential.
-
The best architectures, requirements, and designs emerge from self-organizing teams.
-
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
These twelve principles can be summarised into four key pillars that make up agile software development:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responsiveness to change over following a plan
Let’s take a look at these four points in more detail.
Individuals and interactions
Agile development recognises that software development teams are made up of humans and that a project’s success requires more than just technical expertise. It therefore encourages regular and open communication between team members, which can include face-to-face conversations, daily stand-up meetings, or other forms of regular communication. This creates an environment where team members feel comfortable and motivated to share their ideas and feedback. Let’s look at some of the ways we can create a collaborative environment that puts individuals and interactions over processes and tools.
Collaborative feature development
When new features are being brought to a team, you should include as many of the people who will be working on that feature as possible in the conversation (and not just developers). This prevents information from being siloed, which can happen when designating technical responsibility to a single person, and can ultimately lead to better technical and visual solutions as you have buy-in from multiple people (ideally the whole team).
Single feature development
It’s also important that you ensure each team is working on one epic at a time (usually an epic makes up part of a feature). Working on multiple epics simultaneously can lead to siloed information and an additional time cost from context switching, leading to longer code reviews and feature verification. Working on a single epic keeps the team focused and aware of what everyone’s working on, making the team feel part of a collaborative environment by allowing them to contribute to a single, shared goal.
Clear vision
Following on from this, it’s important that there is a single, shared vision across the company, which each person in the team is aware of and helps contribute towards achieving. The ultimate responsibility of what this vision is should be decided by someone high up the chain (e.g. the CTO) and should be influenced by a range of factors, including customer feedback, sales statistics and company goals. Having this shared vision creates an environment where everyone is aware of what is expected of them and how their work contributes to the overall success of the project. When everyone is working towards the same goal, it's easier to make decisions and prioritise tasks, leading to a more efficient and effective development process.
Working software
This is software development, right? So, we want our software to work! In agile development, we aim to deliver working software at regular intervals. This approach provides transparency and visibility into the project's progress, building trust with stakeholders while ensuring the project is completed on time and within budget.
By delivering working software early and often, the team can adjust their approach, identify potential issues, and pivot if necessary. This flexibility is a key aspect of agile development and allows the team to respond to changes quickly. So how do we actually achieve delivering working software early and often? Let’s take a look.
Continuous delivery/deployment
Continuous delivery and/or deployment are key practices within DevOps that help to deliver working software early and frequently. These practices build upon continuous integration, which is a combination of trunk-based development, where developers create short-lived feature branches and merge their code into the
main branch frequently, coupled with an extensive set of automated tests, which ensure the main branch is always production ready.Continuous delivery builds upon continuous integration by automatically deploying code that passes all tests into a staging/test environment. Pieces of work can then be verified in this test environment before manually being deployed to production. Continuous deployment takes this one step further by deploying code straight to production if it passes all tests. Check out this blog post to learn more about the benefits of trunk-based development and how you can use tools like Vercel along with continuous deployment to completely streamline your development and deployment process.
These practices take away the complexities and risks of large releases by allowing developers to integrate their code frequently and quickly, while also preventing the headaches and frustrations that can happen when rebasing long-lived feature branches. A continuous delivery or deployment pipeline is a vital part of a well-oiled software development team, allowing them to deliver working software early and often by decreasing risk, increasing reliability and accelerating the speed at which code can be merged and deployed.
Single feature development
Let’s emphasise a point we made earlier - ensure that each team is working on one epic at a time. The additional time cost paid when developing multiple features at a time leads to slower deliveries and reduced code quality, due to context switching and information siloing. Single feature development gives teams a shared, focused goal and allows them to gain a deeper understanding of the functionality they are building, leading to better quality code, faster code reviews and fewer bugs. This results in faster releases and a more effective team.
Work in progress limits
Another effective method to aid delivering working software early and often is to impose work in progress (WIP) limits across the team. Working on multiple tickets at a time creates the same problems for developers that working on multiple features at a time creates for teams. It’s also important for the team to realise that features are only finished when they have been deployed to production and can be used by the customer. Hence steps later in the software development lifecycle, like code reviews and quality assurance, should be prioritised, as they are the steps closest to getting the features into the hands of the customer. This is clearly laid out in the twelve principles of the agile manifesto:
Working software is the primary measure of progress. In other words, it doesn’t matter how many tickets you have started, it matters how many tickets you have finished.If you are using a system like Kanban to visualise and manage your workflow, you can impose WIP limits by setting a maximum number of user stories that can be in any one column (a good starting point is number of developers in the team +1). For example, if the
Code review column is full, then no developers can move new tickets into that column until code reviews have been completed for the tickets currently in that column. This creates an environment where upstream columns pull tickets from downstream columns, which stops developers from working in isolation, encourages collaboration and ultimately gets features delivered to customers faster.If you’d like to know more about Kanban and how it can be implemented, check out our blog post on Lean software development.
Iterative development
One of the key aspects of agile is iterative software development. Building a completely perfect and polished feature from the outset may be tempting, however this is not the aim of agile development. Instead, we aim to create a Minimum Viable Product (MVP) which is then iteratively improved as feedback is received (more on this later). Every iteration is a learning opportunity to check whether we are heading in the right direction. This encourages experimentation by allowing the team to test ideas quickly and cheaply, allowing teams to fail fast and pivot if necessary, meaning teams don’t ever spend too much time building the wrong thing, which can be detrimental to a company’s growth and success.
Iterative development is achieved by working in sprints, a repeating, time-boxed period (usually 1-2 weeks), in which the team will work together towards a single, shared goal. Feature epics are broken down into small, manageable chunks of work (known as user stories or tickets) that are estimated in terms of their complexity using (story) points.
Customer collaboration
At the heart of agile development is customer collaboration. When working in an agile manner, the customer plays a major role in the development process. As mentioned previously, we want to get an early prototype (MVP) in front of the customer as soon as possible, and then continue to gather feedback from them at regular intervals (the shorter the timescale, the better). This approach helps to ensure that the project is heading in the right direction.
By involving the customer from the beginning of the project, regularly seeking their feedback, and accepting that things will change, agile development ensures that the project meets the customer's needs and results in a product that delights them. Let’s take a look at some of the ways we can gather feedback from customers.
Gathering feedback
There are a few techniques you can use to gather direct feedback from your customers. Net Promoter Scores (NPS) are a simple but effective way of gathering feedback from customers and gauging their satisfaction with a product or service. They measure customer satisfaction and loyalty by asking them how likely they are to recommend a product or service. Online surveys and simply sending emails can also be used to gather feedback from customers, as they are both cheap and quick. Utilising prioritisation techniques such as the MoSCoW method (Must have, Should have, Could have, Won't have) can aid you in determining which features are most important to customers. Reaching out to customers on social media and utilising company-customer forums can be a useful way to interact with customers (e.g. Monzo, who used these methods to get feedback from people to come up with the name ‘Monzo’ when they were legally challenged on the similarity of their original name Mondo). And finally, the most effective way to gather customer feedback is meeting with customers directly, which can uncover customer’s true needs, experiences, problems and goals.
Gathering analytics
In addition to reaching out to customers directly to gather feedback, there are several other approaches you can take to gain insight into their experiences and pain points. One such technique is the use of web analytics tools, such as Google Analytics, Segment and LogRocket. These tools allow you to track user behaviour on your site, including what pages they visit, how long they spend on each page, and what actions they take. By analysing this data, you can gain a better understanding of how users interact with your site and identify areas for improvement
Another technique you can use is A/B testing. This involves showing different versions of your site to different groups of users and measuring the impact of each version on user behaviour. By comparing the results of these tests, you can determine which variations are most effective in achieving your goals and make data-driven decisions about how to optimise your site.
It is important to note, however, that not all metrics are created equal. It is easy to get caught up in vanity metrics, such as page views or signups, which may not actually be indicative of your site's success or user satisfaction. Instead, focus on metrics that align with your business goals, can be clearly measured in terms of cause and effect, and provide meaningful insights into how users are interacting with your site.
Responsiveness to change
Responding to change is almost impossible in the traditional 'Waterfall' software development methodology, because the project is only presented to the client at the end of the cycle. Agile development avoids this problem by involving the customer from the beginning of the project, regularly seeking their feedback, and accepting that things will change. This ensures that the project meets and exceeds the customer's needs, resulting in a product that delights them.
Being respondent to change follows on from the process of gathering feedback. This feedback should be used to steer the direction of future development. If you’re already heading in the right direction, great, keep going. If not, don’t worry. Negative feedback isn’t a bad thing, it’s a learning opportunity that provides us a with a chance to pivot, reassess where we’re going and start moving in the right direction. Because we’re moving carefully and iteratively, we welcome negative feedback because it prevents us from spending too much time building the wrong thing. This is what’s meant by the Agile Manifesto’s
Responsiveness to change over following a plan. Let’s now look at how we ensure we can respond to change effectively.Iterative development
We’ve mentioned this previously, but there’s a reason why iterative development is a key part of agile. Imagine this - your product team plans out a complete feature that they think the customer wants, which then passes to the design team who designs the feature to complete specifications. The development team then starts work on the feature, and after the first sprint delivers the first iteration of the feature. Upon gathering customer feedback and analytics, it’s found that actually the customer has no desire or intention to use said feature. How much time and resource has just been wasted by the product and design teams? Could these teams not have planned and designed a first iteration of this feature, which the development team could’ve picked up in exactly the same way, resulting in the same feedback without all the time and resources lost?
Hence iterative development should happen across every part of the company, not just the development team (the practice in which only the development team works iteratively and in an agile manner is sometimes known as Scrum-fall). Often companies see methodologies like agile and lean as methodologies that only apply to developers, when actually they are meant to apply to the whole software development lifecycle (which includes all parts of the business!).
The takeaway from this is - iterate as business, not as a software development team. This links back to our earlier point about having a shared goal across the company. Teams should strive to validate their ideas and pivot if necessary in unison.
Backlog prioritisation
The way we achieve iterative development while still moving closer towards our goals is by prioritising and reprioritising the backlog of work to be done. This reprioritising should happen after every sprint, which in turn should be every time we learn something new about our product and our customer. Once we’ve released a sprint’s worth of work to the customer, it’s time to reassess our progress and realign our goals.
Summary
Hopefully this blog post has given you an insight into how you can be more agile in your software development process. By creating a collaborative development environment, iteratively delivering working software and using customer feedback to steer the direction of development, you can quickly build products within budget that delight your customers, ultimately driving growth and success within your company. If you’d like to know more about how Contic can help you achieve the things laid out in this blog post, please get in touch!
Related posts