Agile - Moving Fast

We always here about Agile, and think about which methodology do we use, what practices do we have, team velocity, sprints

But at the end of the day, Agile is intended to be fast, it is all about productivity, So weather you are using Scrum or Kanban, weather you do a Sprints and demos and retrospectives or not, there are somethings that if followed, will really help you be very productive, and by definition ... very agile

Git flow & Tags

Following Git-flow is really important for productivity, even if you work alone, having features separated on branches makes your life easier when a feature is blocked so you can switch to another one on another branch

also making sure that big code refactors are done on there own feature branches at the right time saves you the over head of conflicts when not expected, refactoring is a daily practice when you try to keep your project clean and maintainable, but you must plan for big refactors and arrange this with the team, moving files from one place to another or renaming classes that are used in many places in the code is not a good idea when it is not planned, you can easily refactor these classes from inside, and move them later when you agree with the team to do so, and have a task for this on your board (like JIRA for example)

also using tags with your releases makes it easy to move around your code history, and revert back to stable points if any thing went wrong ... you can use tags with internal releases or test releases, not only releases deployed on market

bottom line is ... branching is your ultimate tool in keeping your app stable, weather by keeping unstable code on separate branches, or reverting to stable code at any point of time ... if you can keep your app stable on market, it is safe to go fast and deploy fast, and if any thing goes wrong ... just revert back till you fix the issue ... and this is a big deal for speed ... for being agile

JIRA

Not only JIRA, any similar tool ... it is important to put the Stories in a way that can be implemented in your branching model, you can think of it like this :

• STORIES will be your feature branches, if a story is too big, it can be an EPIC
• SUB-TASKS are the technical details per story, not a task that deserves it's own branch

for example, as a Mobile Apps Developer, if the story is a user that goes across multiple screens, does something on every every screen, and has to call the server with different API on each screen

we can make an EPIC for this User Journey, each screen will be a STORY that will be implemented on it's feature branch, and any technical details (like working on making repositories and writing code that connects to server and calls the API) are SUB-TASKS in each STORY, as these sub-tasks wont be done on different branches, they are fundamental part of this feature branch

and so on ... this way, the team will not reach a state that a story is blocked on another, or that a Story is not finished in this sprint ... we try to minimize the size of stories as much as possible, each story can be finished in one day or 2 days maximum, and that way we can maintain our speed in having new feature every day of 2 max

CI/CD

Continuous Integration and Deployment is all about automating the process of Delivering the app, to move faster ... no CI/CD will work without Tests, and I mean Unit tests, Integration tests, and End to End tests ... there must be the essential amounts of tests that can tell if this code should be deployed or if the whole process should stop due to an issue in the code

However, the more important part about CI/CD is the automation of fast delivery, the team should have a goal of delivering something every 1 or 2 days max, and also there should be a way to automate this delivery ... like for example, one of the projects I work on, as Mobile team, we deliver a new app version every day to beta users, and to make things faster we made the app update itself once a new version is available.

The Result

This way, we plan our Stories to be deliverable every day or two, and using automated delivery we can know the feedback as fast as possible, and we can fail fast as well so we can fix things fast, and using branching and tags, we can revert to the latest stable version as soon as we discover any issue, and then we can re-deploy our app again after the fix ... our delivery cycle is matter of 1 or 2 days max