Moving on to new challenges


It was not an easy decision – specially when you spend a major part of your life building a company, when your boss becomes not only your friend but also your life mentor, and when you realize that you have a brotherly bond with your colleagues which you never really planned for. But it had to happen one day, and for me that day starts from July 1st, 2015. After devoting 7+ years of my life to Vantage Labs, I’m finally moving on and joining a promising Silicon Valley based startup from next month.
As they say, “A smooth sea never made a skillful sailor”, I’m ready to take up next set of challenges in my career with this startup I’m joining. One of their top goal is to create a cross functional development team based in Bangladesh, who will support their core products, including developing mobile apps for their platform. They are aggressively looking for php hackers, Android/iOS developers, UX developers, and testers who will join hands to form this cross functional team. Salary should not be a concern for a deserving candidate who is smart, gets things done, and an inspiration to work with.

So if you are a php hacker in your blood or a seasoned Android/iOS developer or an experienced UX artisan or enjoy bug stew for your dinner, and you want to be in the team of first few hires of a Silicon Valley based promising startup, feel free to knock me in my inbox. I’m really excited that they put their confidence on the developer eco system of Bangladesh, and I’m confident that with the right team, we will not only be able to meet their expectations, but also exceed at it so that we can proudly say – we have a team of great developers who can crack a problems like any other hyper productive team – anywhere in the world.

Feeling excited already? I’m just a message away. You can also email me at

tl;dr: Leaving Vantage after 7+ years. Joining a Silicon Valley based promising startup. Looking for developers (php/Android/iOS/UX) who want to join the journey with me.

Developer Economy


Life can be considered as the study of attention. Your life grows towards the stuffs you put your attention the most. Chances are high that you are now in a career for which as a child you put most attention to no matter whether the subject was in your course curriculum or not. Same thing applies for relationships. Chances are high that you are now with the person you gave most attention to. Your life revolves around your major attentions. Decades of literatures on the topic of personal growth and self development, including different genre of mediations teach us how to control our attention to achieve our fullest human potentiality.

Now you may be wondering why I’m talking about attention and energy in a post titled ‘Developer Economy’? As a developer, your currency for growth and success in your life is your ability to control and channel your attention to learn and to solve real life hard problems. Attention is also needed to form inter personal relationships which will help you to build your team and work together to achieve more. As a developer we always look for efficiency in our work. The most successful and productive developer out there produces the best ‘return of energy’ when he or she focuses her total attention to a certain task. But if you are not careful enough, current world if ‘mass distraction’ is always out there to rob you from your energy, and attention. A developer who isn’t attentive with his work produces garbage and sometimes does more harm to the product than doing good in the long run. It applies for both technical tasks and also capacity to build successful productive teams.

As the job of attention is to focus your energy, to reach the level of hyper productivity and creativity, you first need to ensure that you have a high level of energy to start with. But there are carefully designed subtle energy leaks all around us. Energy leaks are both inside you, and also out there.

Let’s look inside us first – how are we robbing ourselves of our energy? It starts with negative thoughts and anger. Negative thoughts are major energy leaks and the stronger you get with your emotional intelligence the better you can handle negative thoughts in your life. Negative thoughts will be there, and they will constantly try to rob you from your energy – but it is your response ability towards those thoughts which will give you utmost control to protect yourself from them causing any energy leaks. You should also limit the channels using which negativity can start polluting your thoughts – like controlling your habit of checking social media in every hour, or checking on news headlines in every other hour.

Another major energy leak is anger. Uncontrolled anger causes a short circuit in your positive energy level and leaves you with a feeling of depleted and devastated. You need to learn to control your anger and channel it in a creative way so that it helps you increase your energy level, rather than depleting it.

There are people who will swear by the effectiveness and success of the power of goal setting and meditation in their lives. But if we try to simplify the process, doesn’t it all boil down to enhancing one’s ability to control his or her attention? Daily goal setting and personal mission statements are tools to keep someone on the track by bringing back his attention to the goals he has prioritized in his life. Visualization techniques in meditations also strengthens ones capacity to laser focus his attention to the events he wants in his life to unfold. Many of today’s trainings involves teaching mindfulness which is again another tool to enhance your attention so that you can bring your focus to present. You will find this pattern of enhancing someones level of attention in all the self development tools that many use in current world.

The power of attention applies to listening empathically too. Most leaders and managers who are successful have already mastered the art of listening empathically by focusing their attention to it. You may ask, what’s so special about listening, we all do it every day, right? Well think about speaking. We all speak everyday, but of course there is huge difference between someone speaking with colleague at the coffee corner, and a prolific speaker empower others with her speech. Same way listening is an art too, and you will only start realizing the power of listening when you start putting your attention to it.

As a developer, we are constantly connected to the rest of the world through our terminals. And this ‘rest of the world’ is on a constant battle to rob you from your attention, which in turn doesn’t allow you to channel your energy to focus on your goals. Few months back I was so overwhelmed with such distractions that I forced myself out of Facebook and other social medias (including news sites). It helped me – I was able to break my bad habit of constantly checking news feeds and my notifications. Now, as I moved back to using social medias, I’ve learned to use it only as a personal contact manager. I am still fighting not to let it make me a source of attention donor, but it is a battle that I’m winning by actively mastering my attention.

Attentions are needed to grow a habit. And once you have internalized a habit, it will be there with you for your lifetime – all you might need to do is just give a little push time to time to keep it rolling. As a developer, we need to constantly channel our attention to create positive habits which will lead us to reach our potentiality.

There are some tools which I use in my daily life to keep my attention in check on the stuffs which I want to work on daily. To start with, I want to mention about ‘Personal Kanban’. It is a way to sort and prioritize your personal tasks on a kanban board which ensures your todo list is sorted the same way a Product Backlog is sorted for a Scrum team. I also want to mention about the Pomodoro Technique which will help you to laser focus your efforts on the task you choose to do now.

If life is a journey your attention is how you put your control over it. The sooner you learn to master to channel your energy through attention, the quicker you will start enjoying the aftermaths of having mastery over your energy and life itself.

Bootstrapping LivingOnCodes


IT industry in Bangladesh is going through a lot of positive changes in recent years. Along with the government initiatives declaring it a thrust sector – several private software firms are doing good and some are doing exemplary well. We know that we learn from our failures – but there is also a lot to learn form the success stories too — the small battles that these successful IT companies have won and still winning and taking the industry to the next level. As much as I’ve always wanted, but I never could find a medium through which I can approach the tech leads in our IT market and learn from their experiences. I know that there are awesome teams, tech leads, fanatic geeks who are consistently being successful in their private endeavours but what I miss here in our industry is there isn’t any initiative from us – the developers – to learn from each other and collaborate.

That’s why I’ve taken this initiative which I’m calling “Bootstrapping LivingOnCodes” where I want to hear other tech leads’ idea about how we can collaborate together and create a vibrant developers community here in Bangladesh so that we can initiate a community platform where new aspiring minds will find software development apprenticeship, the moderately experienced ones will find leaders to follow and reach their fullest potential as a developer, and the experts can contribute by showcasing their work not only to the local community but also to the world outside so that other global communities get overall idea about what we are working on, our expertise as a community, and our quality of work.

I am really lucky that I’m able to approach some of the tech leads of our industry and initiate the brainstorming session with them discussing what we can do about it. We are leaving all the bags and baggages behind and showing up with an open mind with the willingness to start learning from each other and joining hands together to bootstrap a vibrant developers community in Bangladesh which not only is “living on codes” but also “leading with codes” and opening doors for the future talents so that they can choose the right path and develop themselves as one of the top software developers in current technology world.

So far I’ve got participation confirmation from tech leads of Therap, Genweb2, NewsCred, Widespace, M&H Infomatics, Right Brain Solution, Vizrt, Monico, TigerIT, Vantage (myself), Leevio, Dimik Computing School, Brain Station 23, Cefalo, Selise and few others. I am really looking forward to meeting them tomorrow and hope that together we can achieve more and get something exciting going for our development community which in turn will benefit all of us by allowing the talents to become their very best through our collective effort and guidance.

Awesome Hour of Productivity


Bell of Awesomeness

Bell of Awesomeness

Introduced the “Awesome Hour of Productivity” concept at Vantage Labs Dhaka today. The idea came from one of my own personal productivity traits. I usually tackle the most difficult task first thing in the morning when I start my work day. So at our office I wanted to share this habit with other colleagues so that they also get the benefit of ‘Eating the frog’ right after they are done with their daily standup (SCRUM) meetings.


If you follow me, you already know that we have installed a ‘Bell of Awesomeness’ at our office premise. Now as the teams are done with their SCRUMs, we hit the bell at around 11:30 am and start our ‘Awesome Hour of Productivity’. During this hour we keep all ours phones silent, stop all distractions, and just focus on the toughest task we have that day. The idea is to make it a regular habit as it is more fun when done with everyone in a group.

My favorite affirmation


I’m a true believer of affirmations and during my runs, meditations, and work breaks I come back to my own affirmation set and just go through them as I recollect myself. I’m sharing one of my most favorite one, may be it can help someone out there to get their productivity rolling.

“I know that if I want to be successful at anything, I need to want success for it as much as I want to breath. When I want something as much as I want to breath – nobody can stop me from being successful. The problem with most of us is we don’t want success as much as we want to breath – we just kind of want it. Each day, I’m internalizing this universal fact and making myself better to be laser focused on my next top priority task, and get it done as if my life depends on it.”

Each day start your day with this affirmation and tackle the most difficult task first thing in the morning – you will surely see enormous positive outcome if you can make it a regular habit.

Excerpts from Agile Coaching by Rachel Davies and Liz Sedley


Sharing some quotes from the book which I found interesting: Agile Coaching

  • When a company is in the middle of a reorganization, then people are more focused on keeping their jobs rather than becoming Agile. We would advise against coaching while this is going on because the pressure on the team will be too distracting, and you will probably be wasting your time.
  • To help Agile teams improve, you need to work with the individuals in the team. They’re the number-one experts on how they work and why. Tap into their expertise to reveal what’s holding them back. Listen to their concerns and ideas one-on-one to give you insights on how they can improve. Give them feedback to help them see where they can improve.
  • When you are acting as a mediator, be clear that in this role you can’t take sides. Listen to the problem from each side, and demonstrate that you understand what is being said by restating the problem in your own words. Next, try to detach the problem from the individuals and frame this in the context of the team. It may be useful to create a diagram of effects to explore the forces involved.
  • Make Change an Experiment: Once a team takes the plunge and tries a change as an experiment, team members get used to the new way of working. Now, making the change back to original way of working is the change that they hesitate over. You’ll also notice that each change they adopt reduces their resistance to the next change.
  • Take care about using “why” questions, because they can shound like you’re criticizing when you don’t mean to do so. For example “Why did you do that?” sounds accusing, whereas “What were you trying to do?” sounds friendlier.
  • There is no point asking about what got in the way if issues aren’t followed up. Avoid saying “Let’s take that offline” every time the conversation meanders or someone raises an issue, because this is ambiguous. Rather than scribbling notes about issues in your notebook, write each item that requires follow-up on a whiteboard that everyone can see to create a parking lot for issues. At the end of the meeting, revisit the parking lot to prioritize the items and work out who needs to be involved in any follow-up.
  • A coach acts as the conscience of the team.
  • The whole point of use stories is to ask questions to better understand what users need and to find ways of breaking requirements down.
  • If the team is making one small changes to support live applications, rather than actively developing a product, there may be no benefit in getting the team together to create a longer-term plan. Instead, you might e better applying kanban, which focuses the team on improving the flow of work.
  • The team’s productivity will not improve by wishful thinking and “trying harder.” At worst, it plummets under excessive pressure.
  • Team velocity often slows down a little as the project grows and the software supports more user stories. Plans should be based on the new measured velocity rather than continuing to plan with the old velocity, hoping the magic will come back.
  • When planning doesn’t make sense (lot of bugs to fix, on vacation members) create a prioritized queue of work on the team board. Consider moving to a kanban style of development which doesn’t depend on iteration timeboxes to limit work in progress.
  • Agile teams need to learn how to work together to meet their goals. They are not kicking a ball; instead, they pass software between team members. Each person on the team plays a part in getting the work done.
  • Don’t let them get away with adding a single task labeled “Testing” for each story – this is a cop-out! A few examples of testing tasks are writing automated tests, preparing test data, and setting up environments.
  • The job of testers is to “prevent defects” rather than collect them .If a story is still on the team board, then any problems that must be fixed should be posted there too, where the whole team can see them. Recommend the team uses bug-tracking software only for bugs that are found after the iteration ends.
  • Encourage the team to design for now and to keep their design as simple as they can for current needs.

Full team focusing on a single story VS small surgical teams working on different stories


It may be ideal to have your Scrum team focus on a single story first, complete it with compliance of their definition of done, and then move on to the next story, but in practice we are yet to achieve it. What we have found works best for us is we work like small surgical teams where one developer is assigned the chief responsibility of a surgeon for a story and another (or more) developer is tagged along with him as copilot/assistant. That copilot knows all the details about the work on progress and can act as an alter ego of the chief surgeon when she/he is not available. The situation may be reversed in some other story/module of the product where the previous copilot is playing the role of chief developer, and the previous chief is playing the role of a copilot.

Scrum synergies the chiefs of each story and also the copilots so that everyone is on the same page regarding the goal of a sprint, and overall product goal. When a conflict arises between two chief surgeons where one is needed as copilot for the other one, we fall back to the prioritized sprint backlog and complete the higher priority story first, then concentrate on the later ones even if it means leaving some stories undone.

Online burndown chart generator


Each day during our daily scrum meetings, we update the burndown chart on our Scrum boards. We prefer to do it manually, but I was looking for a burndown chart generator which will give us the initial sketch we need to get started.

I found this blog post very helpful to create our burndown charts online. Nice tool to solve a trivial problem.

What do you do when your Product Owner can’t give you priorities before next sprint planning?


You ask the team what’s most important for the product, plan your sprint accordingly, write down the stories and start your sprint!

In an idle world, you are suppose to have your prioritized product backlog ready before your sprint planning meeting. But it may happen that you have a lousy product owner who forgets to update the backlog, or may be she is sick and couldn’t work on it before your next sprint planning. What do you do now? You have different options:

  • You can stop sprinting and take a day off while your product owner sorts out the backlog for the team. This can be a good break for the team as you know you can’t be sprinting all the time, then you are actually jogging instead of sprinting.
  • You can take a ‘lab day’ and ask your team members to work on what they think important from previous sprint, or previous feedback from sprint review meetings. You hope that your product owner will sort out the backlog meanwhile as your team focuses on working what they think important.
  • You can carry on with you planning meeting without the prioritized backlog. This works if your team has already completed couple of successful sprints and knows the direction of the product. You ask your team what they think important for the product, and form stories from their feedback. You share the planning meeting details with the product owner and give her the option to change priorities/stories as she wishes.

For one of my teams, I chose the last option and so far everything worked smoothly. The team is well into their sprint and product owner is happy after changing one story from the Sprint backlog, and replacing it with one of her higher priority one.

Retrospective: Looking back for a better tomorrow


For a team to go from good to great, it needs to look back and evaluate itself against the decisions it took and figure out how to improve on it as it carries on the development. Sprint retrospective just facilitates that and helps the team to regroup for the next upcoming sprint and get better in the process.

As we are getting matured with Scrum, we find a pattern in our retrospective meeting which matches what Henrik Kniberg says at Scrum and XP from the Trenches. We merged our way of retrospective with Henrik’s way, and found that our retrospective meetings have become a source for motivation for the team, as well as helping the team to improve.

These are the steps we currently follow during our sprint retrospective meeting:

  • What we did good: We start with a positive tone and find out what was good in our last sprint, what issues we implemented from our previous sprint which we thought important for the team. We write down the points on stickies and put them in our board.
  • What could be better: A nice way to find out about the ‘could be better’ ones is to ask the team what they would have done differently if they had the chance to go back to the start day of the sprint using a time machine. We list inputs from all the team members and stack them on the board along the ‘could be better’ column.
  • What is important to implement next sprint: This is where the whole team works together to collect items from the ‘could be better’ column and move them to ‘important’ column. After they are done, we vote on the important items. Each member of the team gets three magnetic buttons and allowed to place on any important items she chooses. She can also choose to put all her votes on a single important item if that one has such importance level.

As I’m involved with multiple teams’ retrospective meeting, one interesting observation I’ve found out that most of our teams have one common ‘important’ issue, which is “Having tech-session between teams.” So, knowledge sharing within and among the Scrum teams seems to be a common goal for our teams.