“Agile Software Development” – the key to getting things done better and faster.
Then why is it that we still see many Software Development companies fail to deliver high quality software with great velocity?
Having good programmers on the team is just one part of the equation (albeit an important one).
In this article, we discuss some of simple strategies that you can use to improve your Agile Development velocity when building SaaS Platforms (or Software products, in general).
Agile Velocity
Let’s talk about Agile Velocity first. What does this mean?
According to Agile Alliance, Software Velocity is the total number of points for items that were completed in a given iteration (generally referred to as a ‘Sprint’).
Strategies to improve velocity
Alright, as promised, let’s start with strategies that will allow us to improve our Agile Software Development Velocity.
Plan
PLANNING – the key to success in everything!
Improve your software velocity by planning things in well in advance. Measure twice cut once. Write amazing User Stories that cover every detail of the functionality to be implemented.
Make sure the developers fully understand every single user-story with every possible alternate scenario.
Discuss success/failure conditions so that all user-stories can be wrapped up in the same sprint without too much back and forth.
Prep-Meetings
Pro-Tip: Did you know Hollywood has a strategy where all actors in a movie or a show sit at a table and recite their lines so everyone is on the same page?
Do a Mob-Table Planning session with all hands involved and go over the requirements and ask open-ended questions.
Anup Marwadi
Conducting prep-meetings is a great way of figuring out if everyone has truly understood the work they are about to perform.
Quick Tips:
- Have developers regurgitate their understanding of the work for the sprint. This is a great way to catch mistakes up-front.
- Have Product Managers reiterate the scope of the work and the success and failure metrics so that tunnel vision doesn’t eclipse the big picture for developers.
Mid-Week Checkpoint Meetings
Have mid-week Checkpoint Meetings to measure the progress and offer feedback/guidance on the software development process.
A simple 30-min checkpoint meeting will help review the work performed and measure alignment. This will also prevent significant rewrites in the overall implementation strategy and eliminate any ‘Lost In Translation’ errors.
Simplify Units Of Work
Most teams do not understand how to structure work within a given sprint. They try to put everything and the kitchen sink in the same sprint causing a lot of anxiety and stress for developers working on the sprint.
Simply the work to be done in a given sprint by breaking deliverables into very small units of work.
Make sure you determine the shortest path to success when building user stories and related tasks.
In order to simplify the unit of work, we need to make sure that most repeatable tasks can be automated.
Web Development
It is so much better to split a complex screen into many smaller deliverable widgets. This allows specific developers to work on small units of work contributing to the overall screen structure.
- Are you building ATOMS that can be reused in Web interfaces? If not, you should consider doing so. This helps build the rest of the blocks on a page rapidly.
- Do you have boilerplate code for plugging Containers, Components etc.?
- Do you have scaffolding templates built for core modules (such as pagination, modal overlays etc.)?
Backend Software
Are you building the underlying infrastructure to support rapid backend development? Infrastructural units such as Error Codes, Logging constructs, scaffolding libraries, boilerplate templates can all be templatized. This will help you move things way faster.
A solid architectural infrastructure definitely helps in writing boilerplate code again and again.
Shell Scripts
Having Shell scripts to generate folder structures helps speed up development. Here’s a folder structure we have for every “domain” context:
Here’s the Script used to generate it:
Running such generator scripts reduces all overheads and standardizes infrastructure setup.
Code Wrappers
Our HyperTrends code literally consists of abstracting layers of complexity into one or two lines:
Consider building code wrappers and abstractions in as many places as possible.
Simplify Databases
It is amazing how many teams complicate databases by packaging too many things into a single release. We follow the following simple rules of thumb when dealing with database changes:
Introducing new objects
If introducing new tables, columns etc. immediately roll the addition of a new column into a release as quickly as possible. This eliminates the fear of having these new columns or tables in production.
Then slowly and gradually build functionality to populate these new tables and/or columns in subsequent releases.
This reduces your chances of going wrong. Imagine if you had rolled out the addition of the new column and the data population process in a single release. How much co-ordination would you have needed? By keeping these in separate releases you’ve significantly reduced your orchestration needs.
Changing Columns
As a general rule, introduce the new column first and roll it out. Let’s say you want to change a column name from “UserAge” to “Age”. Immediately add a new “Age” column and roll it into production.
Write any scripts to move data in a new release.
Now write logic to populate both the UserAge and Age columns using business logic rules/code as a part of the next release.
Ensure that all systems start using the new column. Once satisfied, leave the old column in place by renaming it to UserAge_retired or a similar name. Stop using this column completely.
Remove the column completely in a few months (or leave it in there forever).
Splitting Table Data
Same stragegy:
- Release 1 – Introduce new table with columns
- Release 2 – Scripts and code to continue writing in old table as before, and make simultaneous writes into new table
- Release 3 – Stop writing data into the old table (more specifically into older columns)
- Release 4 – Rename columns as _retired. Remove all references to those columns from code.
- Release 5 – If needed, wipe out these columns using SQL Scripts (or even better, just leave them in there)
CI/CD
Use CI/CD religiously. We have regretted our decision of delaying CI/CD for many projects until the project was at the very last phases of the development cycle.
We lost precious ground experience in fine-tuning our release processes, our orchestration of dependency releases, contingency planning etc.
There is only one rule with CI/CD. START IMMEDIATELY!
Anup Marwadi
TDD
Test Driven Development (TDD) allows you to manage changes in a smarter manner. Without TDD, you are at the mercy of your developers’ intuition skills to ensure that they are testing everything thoroughly. Formalize it. Systematize it and you’ll be thankful you did it earlier.
We still regret those rookie mistakes that went unchecked, or an edge case that no one wrote a test for. Even the best fail.
The best way to prevent the best from failing includes writing BEST TESTS! 🙂