1. The Why (Introduction)
So, you’re a software developer looking for a new job for whatever reason and you’re browsing through jobs at LinkedIn. Several jobs asks for “Experience in Agile development” and you’re telling yourself, well I’ve got that because we had JIRA at the last startup I was working for. You submit your resume, get a call from HR, schedule an interview with the R&D Manager who says they’re the best because they spent weeks implementing Continuous Deployment and the sprint length is two weeks. That really is awesome and a good sign for a well managed company/team (Is it?).
But have you ever asked yourself “Why?”. Why C.I./C.D. is a good thing? What’s the difference between the two? Why a two week sprint? Why do we do standups every morning? What is a “Task”? What does my product/project manager want from me?
This article will answer all of that by its end, but it’s not about why Agile is good or how to implement it. It’s for you the developer, or the team leader, to understand the thought process behind it. To connect the terms that you already know to the reasons and needs that created them in the first place. A bottom-up review of Agile Development Methodology.
Agile was born out of contrast to Waterfall development methodology, which is still a dominating one throughout many industries and enterprises. I’ll briefly explain the difference between the two starting with defining what an iteration is. A much deeper explanation can be found at the Appendix.
An iteration is defined as the amount of time passed between when a need has addressed to when a solution has been delivered.
Need: Our customer wants to surf the web while watching TV.
Solution delivered: Customers have a SmartTV at home.
Iteration: from the time we started defining the spec of the TV till when the TV has reached our customers.
Need: we identified a bug that causes “Hello World” to be misspelled.
Solution delivered: an updated version has been sent to all our customers.
Iteration: from the time we identified the bug till when all our customers are no longer affected by it.
So what is the basic difference between Waterfall development methodology and Agile? The length of the iteration. A “Waterfall iteration” can (and does) take years to execute while an “Agile iteration” in extreme cases can even be minutes. Every aspect of Agile is about one thing and one thing only: to minimize the iteration length and to minimize the number of iterations - iteration minimization.
Why you ask? Your product/backend/web application will sooner reach your customer. That should eventually lead to a better product, a product that the customer wants and will make your team spend WAY less time on unwanted features and maintenance, because you’ll get reviews and reactions sooner and change your plans accordingly based on inputs and data and less on guesses and assumptions. (If you’re interested in how does a Waterfall project looks like v.s. an Agile project, read the Appendix).
3. WTF is C.D. good for?
Agile Development methodology has a lot of elements that will help you achieve it even with minimal implementation. Let’s review some of the basic ones, the ones you actually already are using, and see how they relate to the Agile goal of iteration minimization. By the end of this section you’ll see the entire puzzle of elements solved.
Sprints and Tasks - the basic building blocks
What is the simplest way to shorten an iteration length from years to weeks? Time limit it!Consider the following scenario. One morning you wake up to this announcement: “As a team/company we decided that once every X weeks (Usually between 1 to 4 weeks) we’ll be delivering a new version to our customers”. Tada! Almost nothing was done and your team already have shorter iterations and working in Agile!
Several weeks of work packed together are called a Sprint. What will this new version or this Sprint will include? Tasks! (There’s also Stories, but we won’t discuss the difference between the two as it has no effect on the minimization itself). A Task can be anything from a small bug to an entire new service - but A single Task must be done at most(!) within a Sprint. But wait.. You’re probably thinking that there’s no way that this entire new service can be done within a week. That’s true - so break the Task to smaller ones. (e.g. each Task is one of the CRUD operations). How small? Small enough to “fit” into a Sprint of course!
By breaking a Task into smaller Tasks you’ve also gained the flexibility of assigning them to different team members and parallel execution of them.
Micro-services, by the way, is not an Agile element but comes handy. Breaking a software project/applications into services is first of all a technological approach (with lots of pros and cons), one that also allows you to break the project into smaller Tasks a-priori.
TDD, Unit Tests, Integration Tests and Continuous Integration - don’t break production
Breaking your software adds an iteration. Prevent it from happening.
C.I. is basically a build server, a remote server that compiles your code and runs all your tests. It will do nothing without Unit Tests or Integration Tests. Test Driven Development (TDD) is an approach saying “code test first, then code”. One outcome of it is to make you code tests as a must (nobody loves coding tests). Obviously, more tests and better coverage will reduce the chance/risk of breaking your production environment or coding a bug. If you did do that by mistake you’ll add a Task to fix add and will require another iteration - which definitely is preventable with C.I.
A/B Testings - Validate before you invest
Do a minimal test to validate before you execute
Have you ever got this really weird Task from your product manager to add a button that does nothing but popping a “Coming Soon!” message? Nonetheless, show this button to only 10% of your users?
Why do I “The Developer” have to waste my precious time and talent on this nonsense? That’s exactly it, it’s about NOT wasting your time with nonsense. Think of the opposite scenario: you spent 2 Sprints developing this amazing awesome innovative feature and finally added the button that executes it, but nobody, except maybe someone in Isle of Man, pushes that button because nobody actually wants to use it. You’ll be blaming everyone for time wasted for another Sprint and maybe even hang the product manager who thought of it in the first place. So that’s a few weeks of work and iterations spent (and a now dead product manager) that could have been avoided - if you along with the product manager would have first verified that your customers actually want it.
Continuous Delivery (Deployment) - optimal iteration minimization
Iteration is not over until you deliver. The faster the delivery the shorter the iteration.
The goal of a good deployment mechanism is for a new version of your software/product to reach it’s destination (servers, client or customers) as soon as possible and as easy as possible - hopefully with a push of a button. As a rule of thumb, if the deployment process annoys you as such that you’re thinking twice before deploying - it’s not good or automated enough. If you didn’t deploy, you didn’t deliver and the iteration length increases. Agile is about shortening it, not the other way around.
Continuous Delivery is about what triggers a deployment and when. C.D., like Sprint, is to limit iteration length by an automated delivery schedule or an event. You can have a scheduled overnight delivery that runs every 3 nights - and that’s C.D. by definition. At most, you must deliver by a Sprint end. If you have a trigger/schedule that when a Sprint ends a delivery is executed - that’s C.D. (btw can be done with Hooks to JIRA).
So, what’s the need for C.D. if I already have Sprints? The inevitability. Sprint doesn’t have to end with a delivery. But with C.D. - you deliver at the Sprint’s end no matter what. That’s another form of restriction to work in short iterations. If you did implement C.D. than the iteration length is defined as the amount of time that passes from one delivery to another - which we want to minimise. (Sidenote for product/project managers: if you have C.D. you technically don’t need Sprints. Consider switching from Scrum methodology to Kanban).
A good C.D. is not schedule based but event based. An optimal C.D. is a fully automated deployment execution for every event / small change in your software/product. Remeber what is the smallest change possible? A Task! You’ve come full circle. Horrah!
(Technically speaking, such C.D. is an execution of full deployment every time a branch is merged to master in Git)
This is not always a good or required thing. For example, something I recently learned was that when you want to deploy a new version of your iOS app, you have to wait for Apple’s approval. You won’t be sending several versions a day to Apple. C.D. is also hard to achieve If you don’t have a fully automated deployment mechanism, which is a must and can take several weeks of work. Think twice before you’re fully committed to it - but at least strive for it.
So what is C.D. for when it comes to Agile? If you automatically deliver every time a Task is done with, then the iteration length is equal to Task execution length + a constant delivery time. If a Task is the smallest change possible then the iteration length is as small as possible - and you have achieved iteration minimization.