I recently got a question from an awesome colleague of mine whose team was to be part of a upcoming big project. The team estimated their part of the project would take at least six months to build. My colleague had read about the agile principle in a previous blog post which says “Never start working on anything, unless you can deliver something of value within a few days.” From experience, big projects are typically slow moving and it often takes months before a first integration is attempted. Thus, his question was how the principle could ever work in a big project.
I didn’t know the specifics of the project so my answer was that, in general, I would approach any problem by “building a first super small thing“.
Build a First Super Small Thing
To illustrate what I mean, let’s use an example with a web application that communicates with a micro-service backend which in turn communicates with other micro-services. Let’s assume the project is about extending an existing web application and backend.
- As iteration 1, I would add the simplest possible web UI element. When the UI element is used, it calls the backend. The backend simply returns a hard-coded response. Also, I would add a UI test for this small functionality! It doesn’t matter if functionality is expected to change later, refactoring of tests should be expected. Even for a small team, this should take no more than a day or two.
- As iteration 2, the backend would do a real HTTP call to a mock server. The test should still pass. Setting up the mock server should take no more than a day or two.
- Iteration 3 would be to actually let your backend call the other micro-service, which would in turn return a hard-coded response. Getting this to work would take another day.
Notice here that, within a week you have your first integration in place!
And then you iterate, adding small thing after small thing. First you add tiny variations of the happy path, one by one, and tests for those. Then perhaps some corner cases, one by one, or input validation. After that, more and more gracious handling of error cases (error handling from the start is just a catch-all and a generic error message, but still fully functional) and so forth.
I would definitively recommend you to deploy every small thing to production, with a configuration setting to enable/disable the functionality. At some point, it will be feature complete enough to turn on for early adopters, and later for general availability.
But wait! What about big new projects? What if there’s no existing infrastructure or build servers available? It usually takes months for a first thing to run.
To me, we cannot blame the new project for this. Instead, it is a result of how big organizations typically work. It shouldn’t be hard to find day-sized things to implement.
- As iteration 1, I would manually spin up an instance on AWS. Then I would manually start a web server with an endpoint returning a hard-coded response. You can find tutorials that does this in less than an hour, so doing it in a day should be no problem. I would also add a test case.
- As iteration 2, I would create a script that automates the first step. Again, there are plenty of short tutorials, so this should take another day at the most. The test should still pass.
- As iteration 3, I would set up a Jenkins instance that runs the script when code is committed.
- As iteration 4, I would create the simplest possible web app and serve it from our web server. Add a UI element and continue with the instructions from our first example.
As you see, the approach with building new services is to manually set up something working, lock it down with tests and then automate, step by step. Apart from this, iterations for new projects are very similar to those for existing software.
The Beauty of Real, Running Things
Normally, value comes from software that makes the customer happy, that he or she can use. The value in the early iterations is different and comes from the feedback and learning we get from having an application people can try out. Never mind it’s not complete, people love to play with real, running things! Quick iterations with running software allows users to give you feedback in order for you to build the right thing.
The main takeaway from this article is that, by following the thinking in the above examples, you should always be possible to find something of value to deliver within a few days! I would challenge anyone that claims to have a project that cannot be broken down into sub-week or even daily iterations. 🙂
To help you in your daily work, we’ve summarized the principle and some additional guidelines in a free PDF guide for you.
Please comment on your own experiences, problems and solutions in the commentary fields below! Thank you.