By Nick Butler
Tags: Agile , Development
The drive to deliver working software is at the heart of Agile frameworks like Scrum. Find out why, and learn how you can deliver working software every Sprint.
There are two reasons:
The drive to deliver working software is spelt out in one of the four values and four of the twelve principles of the Agile manifesto.
This is reflected in Agile frameworks like Scrum and Extreme Programming. Scrum specifies that you build a usable and potentially releasable Product Increment each Sprint. XP relies on short development cycles, resulting in early, concrete and continuing feedback.
The reason it’s a central tenet is that it works. Projects that deliver working software every Sprint succeed more often, because they learn more often. Every Sprint, you can gather empirical evidence of how well you’re meeting your project goal, because you can check how well your latest Increment meets the needs of your users. The longer you wait to learn, the greater the risk your product won’t be fit for purpose.
This is really two questions:
In Scrum terms, it’s a usable, releasable Product Increment that lets you learn more about how to achieve your product goal.
It’s software that you can put in front of users. It helps them achieve something useful, it meets your quality standards and it’s integrated with the rest of your work to date. In short, it meets your Definition of Done. Find out more about the Definition of Done, and how it helps you deliver working software every Sprint.
While it’s releasable, it doesn’t need to be released. You can still learn by testing prototypes or in non-production environments.
Additionally, while you want to deliver working software every Sprint, not every single story in your Sprint needs to do so. The learning you get from, for example, user testing a paper prototype can deliver value as well.
To put it another way, what, of all the work in your backlog, do you choose to build?
You want to build the smallest, simplest usable implementation of your highest priority requirement.
This is absolutely crucial.
The short iterations of Agile mean you need to keep your batches of work small if you’re going to deliver working software each Sprint. Find out more about why and how you keep your batches small.
Let’s assume you detail your requirements via user stories. How do you strip your story back to the minimum that will deliver value?
Minimise the:
Remember, this isn’t your final implementation. Don’t be embarrassed if it’s basic, be proud. You’ll be able to refine in the next iterations. And you’ll be able to do this based on an empirical understanding of what users want from the feature.
Where software has multiple architectural layers (such as Data, Services and User Interface), you could:
You need to build a vertical slice to have something you can put in front of users to get concrete feedback.
To do this you need a cross-functional team. You want to avoid hand-over because that slows you down.
Your rule of thumb will be: You Ain’t Going to Need It (YAGNI). Just build the minimum at each layer needed to deliver the feature you’re working on.
Note that later stories may only work on a single layer, but you need the full height slice to start with to give you something usable.
The highest priority work is that which is most valuable. There are lots of ways to determine value though. As well as value delivered to users, it might include costs saved, risks managed and what you can learn once you’ve delivered working software.
You can learn more about prioritisation for Agile projects here.
You need to be set up so you can deliver quality at speed. This requires fast feedback. Additionally, automation speeds up your work and increases predictability.
It’s crucial to have a Product Owner who is able to quickly and decisively clarify requirements, provide feedback on work in progress, and check that stories are ready to be accepted.
You’ll also want your designers to prioritise design reviews and your developers to prioritise code reviews.
You need interrelated practices that together provide fast feedback and predictable results, including:
Using frameworks can speed up development, helping you deliver working software every Sprint.
We use Ruby On Rails for our web applications for just this reason. We’ve found it gives the best combo of rapid development and a robust foundation for growth.
For mobile apps, it’s cheaper and faster to develop one hybrid app than it is to develop two separate Android and iOS apps so we’ve found frameworks like Ionic or Flutter are the way to go.
For the front-end, we’re also able to get up and running quickly using frameworks like Foundation.
In Test Driven Development you first write a test that defines what the code for a feature is supposed to do. You then write only the code needed to pass the test. Next, you run all tests to make sure your new functionality works without breaking anything else. Lastly, you refactor to make any future changes as simple as possible.
Automating this testing makes it faster. We test our Rails applications via RSpec, with Capybara to simulate real-world users. To test our JavaScript we use Jest. Testing is built into the Ionic mobile app framework and we use Protractor to simulate real-world users.
TDD and automated testing helps you deliver working software every Sprint by:
Continuous Integration means that developers regularly merge the code changes they’ve made into a shared repository. Each merge triggers an automated build-and-test sequence, giving the fast feedback you need. At Boost this includes triggering code review by two people, security and code-consistency checks and, of course, testing that the change integrates without issue into the rest of the code base.
Frequent integration keeps code changes small and simple, limiting the number of moving parts that need to fit together. More moving parts make it harder to find and fix problems.
Continuous Integration is necessary for Continuous Delivery, the drive to get new features in front of users as soon as possible. Practice makes perfect, and releasing early and releasing often (RERO) makes it easier to deliver value to users faster.
We use GitHub as our repository and GitHub Actions to automate the integration and release pipeline.
Continuous Integration and Continuous Delivery help you deliver working software every Sprint by:
Packaging applications into containers using services like Docker and Kubernetes helps you automate and speed up your release pipeline.
This gives you the predictability you need so you can get fast feedback from multiple environments such as staging or User Acceptance Testing (UAT).
To deliver working software every Sprint, you need a cross-functional team that can push changes through the whole pipeline without hand-off. That’s where the DevOps approach of integrating development with IT operations comes in.
Because you’re starting from scratch, you need a ruthless focus on building the smallest, simplest usable implementation of your highest priority requirement. Spend time to nut out the smallest user stories possible. Then review them to see if you can make them even smaller.
You’ll have made some assumptions about priorities in your discovery work. Often your highest priority will be to learn if your riskiest assumption is true.
Only set up the infrastructure required to deliver your highest priority requirements. In particular, avoid setup-only stories.
Having processes that let you bootstrap your projects helps. We have a bias towards consistency and we use templates for many project setup processes. We have a Rails template and use infrastructure-as-code tools like Terraform to automate the setup of our cloud environments.
The purpose of delivering working software every Sprint is to give you concrete understanding of what you need to do to achieve your project goal. This means you need to make sure you learn from each Increment.
Running a demo of what you’ve delivered at your Sprint Review is a chance to learn from your team and stakeholders. It helps if you have a rule that you can only demo working software that’s met your definition of done. The Review helps you assess what your priority stories are for your next Sprint.
User testing is hugely valuable (and Steve Krug’s Rocket Surgery Made Easy is a hugely valuable guide to user testing).
Other opportunities for learning include:
The transparency you achieve by delivering working software, combined with the iterative learning you get from inspecting and adapting this software, is the engine that drives Agile frameworks like Scrum.
