To cubicle, or not, that is the question.

Most things in life has the Shakespearean ambivalence, but I can say without a shred of doubt that there is no uncertainty about the cubicle:

Cubicles are bad.

So “or not” is the right answer.

But if not cubicle, what?

That is where Shakespeare has the upper hand.

Companies large and small, universities and architectural firms have been trying to answer that question with mixed results. Let’s try to approach this with some data that proves quite strongly two things:

1. Proximity matters even in the age of digital

It has been found over and over that the physical proximity of people bring in more positive interactions and collaboration. Team that has team members on the same floor, same room are more efficient than team where the members are physically disbursed (yet connected with all kinds of communications platforms). MIT media lab has done extensive studies on effects of proximity on collaboration a summary of this was done by one of the researchers as follows:

“…the probability that any two people on a corporate campus will interact physically or digitally is directly proportional to the distance between their desks…”

— Ben Waber, Scientist MIT Media Lab

2. Interaction between different work groups reduces productivity

If there are separate groups within the company that work on completely different projects or areas no benefits come in making them interact more, in fact it reduces overall productivity of both teams. Research carried out in a major German bank showed that increasing interactions between teams undermined performance. So they moved teams into separate rooms. 

If you take the above 2 points as gospel then what is the logical conclusion? Keep individual teams together but separate from other teams. Simple.

A Pattern Language: Towns, Buildings, Construction (Center for Environmental Structure Series)

By Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King, Shlomo Angel

And…drum roll please…. we have always known this answer. The answer has been in page 414 of our favorite book on work space design - A Pattern Language by Christopher Alexander.

“The fundamental learning situation is one in which a person learns by helping someone who really knows what he is doing.

…

Therefore:

Arrange the work in every workgroup, industry, and office, in such a way that work and learning go forward hand in hand. Treat every piece of work as an opportunity for learning. To this end, organize work around a tradition of masters and apprentices: and support this form of social organization with a division of the workspace into spatial clusters - one for each master and his apprentices where they can work and meet together.”

With our offices in older brick built houses with small rooms in the older part of Dhaka adopting this pattern has been easy. We can take a group of adjacent rooms (sometimes converting a connecting veranda that is very common in the older designs of Dhaka houses) to form the team space. We try to give the team lead some space of her own, ideally a room all by herself if possible. This makes it easy for her to act as the “mentor” when needed and also acts as the defacto meeting room where conversations (and noisy debates) can happen without disturbing the rest of the team members.

Brick walls ensure that interference from other teams and completely unrelated conversations don’t hinder the flow of the work of the team.

So as I said, Shakespeare has nothing to say to us when it comes to office layout. We got it figured out. But we love him anyway :)

Here’s the famous page 414 btw…

A/B Testing the culture of your company

Wouldn’t it be great if you could A/B test the policies that you take for your company just like you A/B test user adoption for your designs? If we could somehow try our decisions out and then take the one that works better it would take the heartache out of a lot of everyday decisions.

Let’s face it, the way we run our companies, and I’m talking about everyone - from the mini startup to the mega corp., is purely a version of gambling. Let me break down some of the common “rationale” for our policies for the company -

Excuses for bad policies:

“That’s the way it’s done everywhere”

And probably that’s why most companies have dismal work cultures.

“If we don’t do this now, things will go out of control”

As if it’s a kindergarten we are running or worse a prison :(

“There must be checks and balances”

Yeah, but when you have to say it out to justify a policy chances are you are forcing something in that’s no check and no balance.

Anyway, you get the picture (and this is just a rant post). Getting back to my point, A/B Testing - most of the times we are never sure if the policy we are putting in place is a good policy that makes the company efficient and makes the people happy (yes, you can have them both!) or if it will just sap the soul out of the people and lead to inefficiencies and backstabbing. Take the classic “Performance Review” the classic “That’s the way it’s done everywhere” thing. Is it good or bad? Without a performance review your best people will not feel they are being prized or valued. But with performance review aren’t you bringing in competitiveness? Particularly in software development doesn’t the best coder in the world go through a patch of really bad performance (which is offset by 10X performance at other times)? There is no solid gold answer - only “buts” and “ifs” and “depends”. btw if I’ve got you riled up here’s a good read from HBR - Why More and More Companies Are Ditching Performance Ratings

So if we just had a simple way of trying out a policy (maybe in part of the company) and trying something different (with another part) and the checking for the results and pick the one that’s better. Anyway without a foolproof system for A/B testing here’s what we do at Kaz whenever we we trying to put a new policy in place or change an existing one:

Have a “feel out” phase

Every policy we adopt goes through a “feel out” phase where it’s discussed formally and informally during team meetings, lunches even hallway discussions. This gives early feedback about the policy, get amazing ideas of what might work and what might not work and works as great PR campaign for the policy.

Introduce incrementally

All policies are introduced very slowly and in parts. This makes it easy for us to find our mistakes and fix them without making a huge mess. It’s amazing how many times we have fallen face in even when the plan sounded great during our feel out.

Seek feedback

This is the important one - seek feedback from the people who are most affected by the change. There might be some very good ideas about tweaks that might work.

Be prepared to change or roll back

Nothing should be set in stone. As long as we achieve the goal we should not bother about how we achieve it. So if something doesn’t work just change it or roll back. Remember that it’s not a prison that you are running and there is absolutely nothing wrong for a company to admit that it was wrong.

Measure company culture

Now this is hard one. If you can’t measure and put numbers on culture you can’t find out if something is working better or making things worse. But it’s not easy and some would say next to impossible. Our thinking is that you don’t really need perfect system (there is none), as long as you have some measure it’s better than none. So a simple poll might be a good way out, or you can go the full Titanium card path and try something like MIT’s sociometrics (MIT being MIT had to come up with device to measure culture):

We wrote a series sometime back on how we do and did things in quantifying culture The method doesn’t matter as long as you have some way of understanding the effects that you policy changes are causing.

But still, we would love a scheme where we could do those A/B tests easily. Maybe MIT will come up with something? :)

Where is your voice? - Voice design principles

Voice is here to stay. With services like Amazon Voice Service and devices like Alexa or Google home coming up in every home this is the brave new world of software interfaces.

The paradigm shift started when Apple first saved us from the clunky commands in a black DOS prompt back in 1984. This led to the wonderful world of the mouse, the click, the drag and the drop. Then Palm Pilot (remember those green things?) gave the excitement of a tap (more a poke with stylus, but not bad) in 1997. Then Steve Jobs came back to save us again with his iPhone (note to self: do not give a link) in 2007 with it’s fancy touch, pinch, pull and elasticity. We have to thank Jony Ive and his genius for making us humans get closer to technology.

Now is the new shift to two directions - XR with its full immersion on interface where interface is everything to Voice and its invisible interface - Alan Cooper’s dream come true with the most unobtrusive interface imaginable - the no interface.

As with every new design paradigm shift the new world of XR and voice requires us to re-think, re-learn and re-discover the design, development and testing process of software development. We found this with our recent projects in VR in our development and even testing. The same is very much true for voice user interfaces (VUI). A new design principle guides this space - the situational design. Voice apps require that software be designed with:

“Voice First Design”

Voice first design requires us to re-learn our thinking about software interfaces. Here are some pointer to start this re-think:

Expect variability and be adaptable

Each user is different and their use of spoken words is distinct and variable. What works for one, even a group will not work for everyone. All your designs need to take this into consideration, make the interfaces adaptable to user’s change of voice.

…the designer’s job shifts from picking the one label that works best for everyone to providing a range of utterances …

Personalize and individualize

You need to create a personal experience for users, whatever the actual voice device is intended for or your software is used for. The way to accomplish this is very different from what you are used to say for a mobile app where you might have the same popup to display personal data such as list of favorite sites. In voice interactions the interaction must be personalized since the same interaction, say with all the members of a family in the house where your app is running, will feel robotic rather than real and approachable.

Voice-first interactions should offer richer design. They should be predictable yet varied and delightful.

Expect to be called anytime

Gone are the days where users will need to switch on a device, find your app, click on a button to find you and get you to do something for them. They will expect you to be always there, a call away. You have no hierarchy of options - everything is first level, everything is ready to be called at moments notice.

You don’t want to be like those dismal IVRs that keep asking you to press 1 for life and 2 for death, do you?

Converse, be more human

Voice is inherently human like. Users will expect human like behavior from your app. The formality and disconnectedness of an app running in your computer is gone. Users’ expectation will be of a friend ready to be asked something, waiting to help out. Just google what people have been asking Siri. This is the new normal!

OK, done for today, but I have to get Scott Adam’s stab at this new fangled contraption before I go :) As always stolen without a hint of guilt…

3 Questions to define a software product

Imagine you are in charge of creating a clear specification for a new software product. On one side you have your customer - a a high energy, super smart non-techie who flies off in tangents in every discussion yet has the most amazing business idea that needs a web and mobile app. On your other side you have software developers who want a precise software definition that goes over the nitty gritty of what the software needs to do.

What do you do?

Let me go over how we do this with our 3 question approach. This is part 1 in my series on defining software.

Back to the your problem:

How to define a software product?

Every software product we see on the market started from an idea. The idea came from the need. The need presented itself when there is a lacking of carrying out tasks.

This is where the software product management - SPM shines. Understanding the “needs” is the primary goal for any product manager. We use software solutions every day without understanding the true value of it. Mostly because we have it already. There was a time we didn’t have the most basic solution known to mankind, Emails. We can’t imagine that time when it took up to months to send a message, or “mail”, to another person living in a distance.

Then someone asked the question “why?”, the first step to designing a great solution is born with a word. Questioning the limits and vulnerability of the existing solutions. Once it was determined that the existing mail communication is ineffective, the new idea is born.

Then they asked the question “what?”, which is the second most important step to designing any solution. Now knowing the issues with the existing solution, questioning what can be done to improve it will give them more ways to think to replace the existing solution, or system, of communication.

Once they figured out what needed to be done, they asked the question “how?” they can replace the system. The final question to designing any solution, looking for the answers on how to replace the system gave them the access to the tools those were need to create the new solution.

The “why” the “what” and the “how”, the three fundamental questions to defining any products, or solutions. Understanding this paradigm can help any product managers gain confidence for defining products. Product managers’ lives becomes very easy when they understand the answers for these questions. To define a product that you are building, you must go through these questions in step-by-step process.

Understanding the “Why?”

First, the “why” will help you to understand the actual need of the software you are trying to build, for your customers.

The key to understand a product that you are defining, designing and developing, is to understand the need for that product. Without a clear statement of the need if you jump in to the “how” based on some rough ideas on the “why”, it will often result in a product with that don’t address the stakeholders’ requests (no matter how good they look and function well). Most of the time product managers can assume what the customers/stakeholders are talking about when they mention their need but to master it you must start with diving in to details at the beginning of your conversation with them. Ask them why do they need this software/solution, why don’t their current system/process isn’t working, how do they want to their current system/process to function, etc. once you gather the initial needs of your customer, document them to understand their lacking. Investigate the system that they are currently using. Research the answers that you might think is valuable to them and easier for you to design.

The ”why” often usually helps to describe the vision of the product.

OK, the comic strip on the right is just a joke but a really good one, the why should always be aimed at the end user not company that’s profiting from the software!

Awesome “Why?” joke thanks to rstevens

Planning for the “What?”

The next step is to find out “what” can you do to provide a solution (or a product as a solution) for customers to overcome their difficulties. A very good practice is to investigate the process on the Internet and see how many have solved this need. It always helps to learn from your competitors. One bad practice is to jump to the development phase. In this way you may not know for sure, that the solution you have provided to your customers will serve them longer, or they can get any value out of using it, with the tools and technology you used to build the product for the customers. You must be able to plan more than one solution for a single need and try to understand the flaws in them. You can also use the help of UX and other interaction professionals to develop mockups or wireframes to show how concept of the product you need to build.

The “what’ part of the process helps you to capture the requirements, feature specification and milestones.

Deciding the “How”

Now that you know why and what you are doing, you can now jump to code. The third step gets easier when you have finalized what you will be building and why. Now comes the challenge on “how” to build what you have defined. With all the materials, such as business requirements, feature requirements, UX, models, your life becomes more easier to decide on the technology you will be using and design milestones in building the product you defined. This part is where you can race to code to build the product that your customers desire. Developers and architects should be given the freedom to make decisions regarding the implementation process.

In another way of saying, the “how” helps “what” is required to be built.

Concluding

To put a product on the (hypothetical) shelf, product managers have to be very precise in what they define as their product, both for the customers and the engineers. Using the “why”, “what” and “how” approach will help you to achieve that more efficiently and precisely.

How to make software in Bangladesh?

As a custom software development company operating out of Dhaka, Bangladesh for the past 16 years, a question we get asked all the time is “how do we make our software from Bangladesh?”. A variation to this “Wow, I had no idea that Bangladesh is so far ahead in software development". Bangladesh has indeed made huge strides in software development in the past few years.

When we started back in 2004 (feels like ancient times!) there were probably a dozen companies that were actually developing software. We registered as the 248th member at BASIS the official association for software companies in Bangladesh, but of the other 247 most were either dormant shell companies, ISPs, hardware and network equipment companies. The picture is completely different now, with literally hundreds of vibrant active software companies working from IoT to innovative apps, startups with the potential to become the next big thing and many world class custom software consultancies.

In recent report done by USAID - Comprehensive private sector assessment the domain spread of the software companies are described with the graphics below:

This shows how mature and broad the software development industry has become in Bangladesh. So the answer to the question in the title of this article is easy. If you are planning to make your software in Bangladesh you have many choices and you are very likely to find the company that has experience in your business and technology domain. We go over some of your options below:

Use a custom software development company

According to BASIS is there are more than 300+ well established companies who make custom software for their customers. The size varies from a student run small 1-5 person company to major enterprises with hundreds of developers. Accordingly you’ll also find a huge variation in pricing too. Whom you select would be a decision based on your budget and complexity of your software requirement.

Read our article on how to choose a good software vendor if you are new to this game.

Use a freelancer based in Bangladesh

There is a large number of freelancers working from home in Bangladesh. Many are excellent software developers who have worked on large international projects. Thus some of the freelancers have huge exposure and have skills comparable to any you can find in an established software company. Site such as upwork can easily get you connected with such freelancers. You can also find potential freelancers in LinkedIn or various developer forums. If your project does not require a team or if the specifications are well developed and you know exactly what you want, freelancers are a great option.

The only run is the long run - building a great software company

If you want to build a great software company, you should only build it with the long term in mind. This may sound counter-intuitive, after all the software world feels very short term with it’s ever changing technology and trends; and this sometimes leads the people who start and run a software company lose the long term view that most other industries have. Yet this is a fundamental mistake, at its heart the creation of software is a craft and sometimes even an art. And like all creative industry, it takes time, patience and resilience to perfect the creative process and culture.

When you have the long term in mind your mindset changes. Every business decisions you take changes. And all these little changes accumulate to a culture, a psyche and a people who value their work and their creation. This is the time honored strategy for all organizations that trades in the creative output. You don’t need it in a factory or say in a product manufacturing plant but you need it in a software company. Solely because a software company is never a product manufacturing plant. You may have heard it differently, you may even have started to believe it as such but it never is. Many have tried to force the “engineering” into a software company and failed. Many will no doubt keep trying, but I believe until we have built perfect AI bots that write software with built in human empathy, they too will fail.

The moment you bring in the long term you bring in decisions like: “it is better to take in a project that will not burn out my people” or “let’s invest a little more on the team’s ability to gel”. All of these lead to happiness - the magic that brings out the best in humans. And you need that best, for them to find the best solution to a next to impossible problem, or the most subtle way to let the user of their software know that they left an entry blank. With happiness you find passion in your software projects, you find people pro-actively participating to make the product better, challenging themselves to strive even higher.

As we start a new year, our 16th as a company, these are the words we keep reminding ourselves. The long term has always been our goal, even when we started with just three people working in a small room. And 16 years later we are happy that we had always stayed with that as our guiding star. It has not been easy, and we don’t expect it to be easy, but the journey has been amazing and that makes all the difference.

Here’s to a great new year. May this year be your greatest. And may we meet years from now and smile that we had taken the road less traveled.

Top 5 software company growth areas in Bangladesh

Software development industry is one of the fastest growing industry in Bangladesh in recent history.

“The Information and Communications Technology (ICT) and IT-enabled services in Bangladesh have been maintaining a double-digit Compound Annual Growth Rate (CAGR) over the last ten years.
”

— USAID Report on comprehensive private sector assessment

An extensive study on the industry done by USAID reported that the industry generated revenue of $0.9-1.1 billion in 2017 and expected to grow nearly five-fold to reach $4.6-4.8 billion by 2025. This is significantly more than the growth forecast for any peer location such as India which is estimated a growth of 10-13% CAGR for 2017- 2020 or an emerging location such as Vietnam with 12-15% CAGR growth.

With such remarkable growth happening in this industry a question we get asked a lot is in which areas in the IT/ITES sector do we the most growth, what are the areas software companies should focus on to grow and what are the skills that software companies based in Bangladesh should acquire to tap into this growth. Since Kaz started before this exponential growth in the industry (back in 2004) we have seen the whole sector start moving, gain speed and grow as ourselves adapted and expanded with it. This unique experience has given us a lot of insights about the industry and it’s potential direction in the future and today’s article is just a quick summary about areas where see a lot of potential growth for the software companies here. Here are our top 10 list of software company areas for growth:

1. Custom web applications development

This is the biggest and most obvious area of growth for a software company in Bangladesh. This area has been growing consistently for the past 15 years with more and more project both international (outsourced) and local (both private and public sector) focused on web based solutions. Technologies such as ASP.NET/C#, PHP, Java are the obvious candidates for this sector and the availability of skill set is also strong. Most universities now have courses on one or more of the web technologies.

2. Custom mobile applications development

Similar to the web application development this is the other strong and consistent top growth area for software companies in Bangladesh. With most of the world moving towards mobile based interactions and software platforms it is only likely that this trend will continue. Majority of the mobile projects used to be outsource projects but over the past 5-6 years that trend is now augmented with mobile applications for the local market. This growth will definitely continue and be spread between iOS and Android development.

3. Game development

This is a relatively new sector for Bangladeshi software industry. Although several software companies had been making games for some considerable time (including Kaz, which started its first game in 2009) the total number wasn’t large and it was not a growth area. This is currently changing, with game development platforms such as Unity and Unreal making game development easier the barrier to entry has become low, making it possible for most software companies to take on game projects. This is going to be a major sector for the software industry in Bangladesh.

Checkout our article about our experience in making mobile games.

4. AR/VR development

AR and VR are the two new paradigm that will likely change the way we interact with software completely. This change of paradigm will be more radical to the change when users moved from their desktops to interacting more with their mobile screens. This is an obvious are for growth for the software industry in Bangladesh which is largely driven by the outsourced projects.

Read our experience is developing our first VR game.

5. IoT software development

IoT devices are likely to be as pervasive as mobile devices in the next 10 years. We’ve been writing about the potential for this for our software companies for the past few years. This would mean that IoT software development will become a major new direction for the software industry in Bangladesh.

We saw this in action when we built our first IoT device and software for Dutch startup delivering feed optimization for dairy farms all around the world. We see huge industry in the automotive industry’s use of IoT devices and have been working with several companies in developing innovative software platforms.

KAZ SOFTWARE - A LEADER IN THE OUTSOURCING INDUSTRY

Kaz software stands out as one of the top software companies in the IT services industry in Bangladesh. We have been doing software development outsourcing from Bangladesh since 2004. More than 20 companies from various countries of the world has offshored software projects with us over these years.

We believe we are the trend setters for proper development process, company culture and management required for the unique needs of outsourcing to offshore destination. This has been acknowledged by the industry with awards and informal communication putting us a one of the leaders in this sector.

Want our help? We know how to do great software.
To learn how easy it is to outsource your software development to the experts and concentrate your energy on your core business,
email us: info@kaz.com.bd

Software without anger: managing yourself

After our first two articles ( Software without anger: managing the development team and Software without anger: managing vendor relationship ) in this series of anger management in software projects we got a lot of feedback asking us about how to manage anger on a personal level. What can we, as software professionals, do to reduce anger in software project? Be it within the team, with stakeholders and even with ourselves ( this last one becomes obvious when you think about how many times you’ve wanted to bang your head on the table when you realized that you should’ve written that generalized class to validate the data before an insert or something along those lines… ).

So today’s article is about us. Us the software professionals (ahem).

We know we can do a lot (and we should’ve done a lot) to make software projects anger and stress free. Maybe we have our own list of those to-dos. Here’s our attempt at that list…

1. Expect and accept anger as normal in software development.

This one is the same for all of the articles... Since the situation is the same, so I’ll do another ctrl+C and ctrl+V from the first article:

In any endeavor where there is a lot of unknowns and yet the risks and cost of getting things wrong are big, anger is natural. Anger is actually sometimes a good sign in software projects - it shows people involved in the process are emotionally attached to what they are doing and they care enough to voice things out. It is the negative aspects of anger like the blame game, shutting off channels of communications, creating bias, etc. that are destructive that you have to be worried about. If you expect and accept the fact that there will be anger, you can take steps to reduce it, manage it or channel its energy to a creative force.

It is the sudden rush of anger that you don’t expect in the otherwise calm and civil workplace (well for some I hear) that makes us go off balance. Instead of managing it we fumble and make it worse by being irrational and in many a case damage our relationships with others in the team and damage the chances of success in a software project.

The moment you expect anger as a natural outcome, you’ll be able to address it with strategies you know that work for you in other circumstances in your life. The particular strategy that works is very personal. Some people just takes a deep breath, someone I know takes a toilet break! For me the best thing is to stop saying whatever I was saying for a minute or so.

But expecting anger as a natural expected “artifact” doesn’t only mean that you can snuff it out when it comes. It also means that you can take steps to make sure situations that create anger do not happen, I discuss some such ideas below. And apart from snuffing it out, or avoiding it completely, anger can be channeled for the good of the project too! Anger is in essence passion and there is always a good use of passion in software projects! Good project managers us this passion all the time in situations like brainstorming or technical architecture discussions.

2. Prioritize, prioritize and prioritize

This is probably the most important single step you can do on a personal level to manage anger in your software project. There will always be way too many tasks coming towards you and there will always be a looming deadline that’s just too close for comfort. The only way to reduce stress (your own and the team’s when others are waiting for your work for theirs to be done) is to know what tasks are the most important.

Prioritize your tasks. Discuss them with your tech lead or manager. Discuss them in your daily stand-up. Scream (ok, maybe not scream in anger, that would defeat things ) if you feel you’ve been told to do something that you feel should not be high priority. Setting the priority of you tasks should be your highest priority :)

3. Read the spec!

OK, I probably mean understand what you are supposed to do in a task before jumping in to code it or test it. This might mean just reading the task ticket, or watching a video that explains things. But investing a little time to understand the task properly saves a lot of your time later on. It sounds very obvious, but I think we all know that we can be drifting with the flow on a lot cases and just jumping in to the code feels a lot easier sometimes rather than talk to a product manager about something that’s confusing. But that is a recipe for a heated conversation somewhere down the line. Not worth it.

4. Keep an open mind

Nothing in our field is set in stone. No technology is the final word and nothing is perfect. And today’s greatest stack will be the trash of tomorrow. That’s how our space is like, we knew it when we got into this. So there is absolutely no reason at all to be a staunch supporter of a technique, stack, idea, “pattern”, DB, __ (fill in the blanks). If you keep reminding yourself this fact then keeping an open mind is easy, and then discussions and debates about technology becomes finding out good solution for the problem at hand with the currently available skills and technology - rather than a religious war that these discussions sometimes warp into :)

5. Remember that there is always a next version

There will always be scope in your work. You will never be able to finish all the things you wanted to do. Scope your work, do what’s needed now and plan the rest for the next iteration. This helps move the project forward, keeps your boss and your teammates happy and you out of anger.

I’ll keep to the pattern of this series of articles by using a 3 stooges picture. This just one of them.

Software without anger: managing the development team

Isn’t that a great title for an article about software development? If you’ve ever been involved in a software development project this would ring bells!

This was the starting in the first article on this series - Software without anger: managing vendor relationship which goes over the distilled wisdom of 15 years or so that we’ve been around in this business of making software for our customers. That was all about how to manage the relationship with the software team that’s outside your company, say for an outsourced project, or for a team of yours that works offsite away from regular face to face interactions. Today’s blog is about managing your in-house team of software developers, designers and QA professionals. I can never decide if it’s easier if the team is in-house, but I think an entrepreneur is just faced with a different set of problems which require a different set of solutions. So here goes…as promised - a list of - “distilled wisdom” :)

1. Expect and accept anger as normal in software development.

Umm, this the same as with the vendor relationship. Since the situation is the same, so I’ll do the infamous ctrl+C and ctrl+V

In any endeavor where there is a lot of unknowns and yet the risks and cost of getting things wrong are big, anger is natural. Anger is actually sometimes a good sign in software projects - it shows people involved in the process are emotionally attached to what they are doing and they care enough to voice things out. It is the negative aspects of anger like the blame game, shutting off channels of communications, creating bias, etc. that are destructive, that you have to be worried about. If you expect and accept the fact that there will be anger, you can take steps to reduce it, manage it or channel its energy to a creative force.

The only thing to add to this for an in-house team is, since you see the anger first hand, as it starts to pick up steam you have to move quickly. You should never leave a conversation that started moving to anger without diffusing it in the direction of a creative conversation. Striking while the iron is hot is the name of the game for this.

2. Create a culture of celebrating a dissenting voice

A dissenting voice is a voice that checks assumptions, tests logic and make the overall process stronger. It is almost always good for a software development process. The only time you don’t want a good “fight” in software discussions is when ego is getting involved and the discussion becomes a war of words rather than a debate based on logic. So you should make it easier for people to voice their concerns, actually make it welcome and celebrated. That way people will speak out, and feel that it is accepted and is part of the healthy brainstorming that goes on in a team all the time. Taking the taboo out of the dissent makes it feel like professional skill and somehow takes away the purely negative “anger” component out from a discussion where two sides have opposing view.

It’s a delicate balance, but once you create that culture life becomes so much better and your software too!

3. Have a clear and readily available set of requirements at all times

When I say requirements, I don’t exactly mean like spec documents or a bunch of mock-ups. I mean at any point of time the team should have access to resources that make it crystal clear what they are supposed to be making at that point in time. So, to do that you’ll probably need a task management system (e.g. a Jira board), a set of mock-ups that have been scoped and discussed for the task in hand, a meeting or two beforehand that clearly goes over what you are trying to build over next few days/weeks, etc.

As soon as the team knows exactly what they should be making you’ll find that the destructive anger that comes from confusion and that always leads to a blame game goes away. That’s the type of anger you can never manage and resolve easily. Take that out and half of your job is done in anger management in a software project!

4. Always have a confident “supreme court” for final decisions

That’s probably the team lead or the founder or even the designer. It’s not very important who it is as long as there is only one at all time, whose decisions, people know, cannot be overturned and obviously someone who is just (most of the times).

Most tech debates (aka anger) have multiple possible resolutions. Usually more than one of the solutions being debated works great as long as everyone accepts it. But tech debates comes with people who are married to their ideas (“I’ve got a unique solution that no one has thought of”), philosophies (“Java is the best”), past (“It worked for the last project”) and the worst - latest fads (“micro-services is the future”). Many times the only way out of a prolonged discussion, that starts to loop over the same few arguments, is a judge making a call and putting an end to the debate. Not easy to find a judge who can instill that confidence but it’s not impossible.

5. A gelled team is the only way out

At the end, nothing is better than a team that trusts each other, considers each other as friends and are happy to work with each other - a gelled team. Just as in a family or a group of friends high emotions and anger fizzle out because of the strength of their relationships, a gelled team can absorb and diffuse any anger. We have written extensively about gelled teams. This is our big mantra, our grand unified theory, our secret sauce at Kaz Software. This is what makes us good at what we do over and over. Read some of our past blogs for some idea, Two ingredient recipe for a great software team or 5 Easy steps to kill the deadly PDI in your software team or Burn the cubicles - in the pursuit of happiness or the ever so famous Barbecued dog is good for software :)

Since I have the 3 stooges always fighting in this series, let me end with one where they are a happy gelled team which they actually are.

Software without anger: managing vendor relationship

Isn’t that a great title for an article about software development? If you’ve ever been involved in a software development project this would ring bells! And if you have not been, but you are thinking of starting a software company or working with a vendor to make a software you should definitely learn about this. Because want it or not, anger will come. You’d be very lucky if it’s only once in a while that people are angry, it could easily be that the whole project is a series of angry exchanges!

FEAR NOT.

This is a problem that can easily be managed (if not completely avoided) if you take some simple steps. So here goes our strategies for anger managed software project. I want to split these strategies up in separate articles, one about managing anger between you and the outside software development partner, one about strategies to use to manage anger when your developers are in house and the last one about strategies to manage your own anger (remember, you are sometimes one of those angry people)!

Today’s article is about strategies for managing software projects that are outsourced to custom software development company like us.

1. Expect and accept anger as normal in software development.

   In any endeavor where there is a lot of unknowns and yet the risks and cost of getting things wrong are big anger is natural. Anger is actually sometimes good sign in software projects - it shows people involved in the process are emotionally attached to what they are doing and they care enough to voice things out. It is the negative aspects of anger like the blame game, shutting off channels of communications, creating bias, etc. that are destructive that you have to be worried about. If you expect and accept the fact that there will be anger, you can take steps to reduce it, manage it or channel its energy to a creative force.

2. Know that software development is a fluid process.

   The top thing you need to understand when you are managing anger or designing a process to reduce it, is that software development is inherently a fluid process. You just can’t have it structured as precision engineering process (e.g. like a building a bridge) where everything is thought out and can be measured. Every step of the software development process involves reviewing what you initially thought needed to be done and changing it. Remember why Agile process is so successful - “embrace change”. So all your contracts, documents, dev cycles, demos, monitoring, analysis of work should have the possibility of change taken into account. For example your software development contracts with the vendor should have clauses to cover situation where there are changes. Timeline and delivery milestones should have padding for inevitable change. The list goes on.

3. Scope, scope and scope.

   The full software will probably do a lot of things one day (maybe even change the world) but for the small block of time that you are working on, or the immediate delivery you are waiting for will only be for a small section of those things. So you’ll need to first identify clearly what you want to achieve, define and document those features and then communicate that to the developers. You are scoping the limits of a delivery. If you do that clearly, right up front and stick to it (as much as possible without harming your business) you’ll get rid of most of the destructive anger in a software project.

4. Have regular scheduled meetings.

   As the software is being built offsite by a team that is not always in touch with you regularly things can easily go in the wrong direction. It’s essential to have regular meetings at short intervals. That makes it easy to find errors early, give feedback early and get the development back on track faster. Bunching up a lot of development work to be reviewed in one go is a recipe for disaster and fights. It is counter productive and actually wastes much more of your time than the time you thought you were saving but not doing regular meetings. How regular? Depends on the nature of the project, but I will say the meetings should never be more than weeks apart.

5. Create an environment of trust and collaboration.

   For a software project that is outsourced this is a really big one, and most of the responsibility fall on you as you are the ultimate customer as much as the software team is concerned. You set the tone of the collaboration. If you set it so that it’s always combative then you’ll have your vendor always trying to be defensive. They will hide things from you, be less proactive, less likely to point out errors on your part. Set the tone from the start that you have trust and that the project is a collaboration. That will make way for conversations that addresses issues with reason rather than emotion or subterfuge.

6. Always celebrate victories.

   Make deliveries and reaching milestones a big thing. Treat your team to a party, give them some symbolic gifts (even a congratulatory email goes a long way). This celebration renews the relationship, gives it the time to rest and prepare for the next cycle. And most importantly this celebration makes it easy for people to forget bad feelings and make them move on with renewed energy. It is like the restart button on a game gone wrong!

That’s all for today, wait a bit for my other one about keeping your in house development process happy. By the way this article was my chance once again to use old black and white pics stolen from the web particularly of the three stooges. We used to have this as a tradition for all our articles some years ago!

Mobile games development in Bangladesh

At Kaz we’ve been developing mobile applications for ages. When we did our first few apps way back in 2008 (scary!) we learnt our first lessons about how different the mobile space was. We blogged about our experiences.

Over the years we’ve honed our skills and learnt the art of making cool mobile apps that hits the spot. Mobile apps just have to be enough to get your job done without fuss and no more. And while it’s being not fussy, it needs to be uber stylish! Easy we say these days, and love any new mobile app that comes our way. With more than 30 apps under our belt we can certainly say we’ve been around the block!

Today’s blog will be a bit unusual. I’ll just put up some random thoughts and mini-wisdom that we’ve picked up over the years working as the mobile games developer based in Bangladesh.

Mobile games are a different beast

Now in the wide world of mobile apps, games are the most fun to make. But as the title says, they are a different beast altogether. There’s a bunch of things that you just have to get right to make a superb game.

Graphics and play

You’ve got to get the flow just perfect with graphics that oozes with fun and gaming moves that are fun and swift.

Performance

If you have those sorted out then you get into the wonderful world of performance tuning. Making the game fast in a wide variety of devices (if you are covering Android then some historic junks in that mix too!) is a real challenge.

Store presence

And once all of that is done and dusted you have the challenge of making it stand out in the super crowded marketplace. We are a full service mobile apps developer, so we help our customers with everything related to getting the game on store which includes all those cool videos and screenshots that need to get people to download. Probably the hardest part in the story if you ask me!

Now enter in this story the new phenomenon of

hyper casual games

The italic, bold and large casing for this class of mobile games is intentional. They are a Universe on their own. The magic word in this space “fast“. How fast can you churn out a concept and get it live to try out download? See in this world there is no known formula, even the best ideas can die in a matter of minutes. The only thing that a software partner for mobile apps can help is to make the games as fast as possible. We help our customers with these projects by brainstorming out the bare basic game that has the main element of fun in the game play. We get this built in a matter of weeks (usually days) and get them out to the play store for testing out user adoption. The holy grail is user download and retention on day 1 and 5 (hopefully).

New rules for a new ball game.

Anyway, gotta go. Told you today’s blog would be weird one. But if you are looking for a uber cool, super fast software development company for mobile apps give us a ping. We think we can help you. Use the form below to get a free quote for the mobile app you want to make. You’ll be surprised!

Software entrepreneur's starting up checklist

We’ve been helping software entrepreneurs for the past 15 years to build their apps and bring the products to market. Helping startups is in our genes, as we started out with helping fledgling silicon valley startup get back on its feet. And over the past one and a half decade we have helped more than 20 startups get their products released.

We know it’s never a easy journey, it’s hard for the cash strapped entrepreneurs to make decisions about what to build and what to leave out, when and how to release their products, how to get their first customers and how to improve the product from those customers’ feedback. We have helped them navigate these murky waters, and in the process we have learnt a lot. Over the years we’ve blogged a lot of our experience that we want to share with with would be entrepreneurs and today I’ll try to distill our thoughts to almost a checklist of things that every software startup owner should be aware of before starting out on their bumpy ride.

0) Know the basics of software development

It’s the zeroth item in the list because it’s expected. Don’t get into a business unless you know the basics of that business - simple. This doesn’t mean you have to know Python programming or need to know how to SQL join. It’s great if you do (and many of our startup owners do because they were software developers themselves) but your role when you are wearing the entrepreneur hat does not need you to do them and actually it’s better not to know them with that hat (but you might be wearing the developer hat on other times - remember many startups are just a person show!). As an entrepreneur you need to know the basics of how things are done, what fits what and some basic tools. 5 Tools all non-technical software founders should use is a great starting point, but a little more googling will you great tutorials. Khan Academy is a great resource, here’s one that I give out to non-techie owners to start with: What is programming?

1) Find the right developer

Now that you know that you want to build the app you need the people to build it for you. The first step is to decide if you want to outsource this or if you want to hire your own developers to do it (or of course if you want to write it yourself). Deciding to outsource your development or not is a guide we wrote sometime ago to distill our ideas around this. It’s usually straight forward to decide but if you decide to get an external company to build the app for you a much harder question is to find that vendor. How to select a software vendor? gives you some of our thoughts around this, and Testing an outsourcing partner is our cheat sheet for checking on your vendor.

2) Setup the right contracts

Once you found your vendor you’ll need to setup the contracts that protect your software and your product deliveries. Software development is a fluid process, where you need space for both you and your vendor to change and adapt as you progress through the development. Too tight a contract will make this process difficult and bring up frictions that are hard to remove leading to a bad software or no software at all. Too flexible a contract and you are at risk of getting a bad deal or a really bad product. Our article 5 things every software contract needs shares our ideas of coming up with contract that works.

3) Run the right process

When the software is being built there needs to be a set process for interacting with the developers. You’ll need to monitor but not start breathing down their necks. You’ll need to prioritize, guide and help the team navigate with your business priorities in mind since the goal of the software is clearly to bring in business but you’ll need to be careful not to derail things in the way. Not an easy task, but 5 things a software entrepreneur must remember gives out some of the advice we give to our startup owners.

Top software company in Bangladesh

We became 15 this year. Starting from a small startup with just four people to one of the top software company in Bangladesh has been a long journey. There is a lot that we have learnt on the way and in today’s blog is about the lessons we have learnt in journey to becoming one the best software company in Bangladesh.

It is all about the developers

A software company is as good as it’s developers. And if we don’t hire the best developers, if we can’t keep them motivated, if we can’t keep them trained and happy we will fail. This is the very core of our philosophy at Kaz. Everything we do, every policy we adopt, every rule that we set, every decision we take is based on this core concept. We test if our change will make life harder for our developers. If it does we will always discard it. This formula has made us one of the best places to work and grow as a developer in Bangladesh.

Hiring the best

There is no way around this. A software company is only as good as the skill of its people. If you don’t hire the best talents there is no way you’ll be the best IT company around.

The real challenge in hiring the best is of course finding, attracting and retaining the best talents. That’s a full time work for a company. It is not something you can stop and start once is a while. This is something that has to be in the top of any long term or short term strategy that the company adopts.

We think we have been relatively successful in attracting the best talents in software and IT in Bangladesh. We’ve have written in the past about some of our “secrets” (not really any secret though, just common sense). Here’s one about our interviewing process that has helped us a lot: The dumb interviewer

Keeping the edge sharp

Software is such a field that if you are not up to date you are simply not good enough. To be the best in software development you’ll need to keep your talent always up to date with recent developments in technology. And this something that we do as a priority.

Knowledge is something that you can’t just tick a box and it gets done. You need to setup a system that automatically encourages people to learn and makes that process a constant thing. We have various methods for this, starting from simple seminars and workshops to multi-day training sessions and code camps.

We were the first company in Bangladesh to bring in internationally renowned trainers and speakers to train our staff. Our multi day on site training with people like Naresh Jain, Industrial logic, IBM research faculty, various university faculty members and our internal senior staff has made a huge difference to the skills and expertise of our employees.

A creative work environment

Now that you have the best talents and they are all trained to go don’t think that would automatically lead to the top software company. The missing piece in this is the setting the backdrop for your talents to work in. A work environment for creative space such as software development needs to be tuned, so that the software developers feel comfortable and creative. There is a multitude of things that you have to do to make this work and we have written extensively about what we do at Kaz to make this happen. We think the start is setting up the physical work space, here are some details about what we do in that aspect: work space design for a software company . Once you have the physical aspect covered you need the not so tangible team effects to kick in, here is an article we wrote that describes this element: recipe for a great software team.

And then there needs to be close eye on the culture of the teams. We have always been careful to monitor this and trying to quantify it (not an easy task for sure).

I think these elements has enabled us to deliver amazing software products over the past 15 years. Making us one of the top software and IT companies in Bangladesh. Here’s a quick facts numbers I stole from one of our presentations. Companies from one person startups to Fortune500 giants trust to make their software solutions.

That’s it for today!

"VIVE Vibe" - making the first VR game

As with the rest of the software world we were excited about the possibilities of VR and getting our hands dirty with some VR code. So it was with a big smile on our face that we took in our first official VR project. And not just any boring "also ran" VR app but a full blown first person shooting game!

Nothing compares to writing a game. Add to that the total immersive environment of a HTC VIVE (our first target platform) you have something that literally stops us from living in the reality of this world :)

I'll be writing here about our experiences in this first serious dabble in the world of VR. Here are somethings that we wish we knew from the beginning...

 

 

Virtual reality is a whole new ball game

Duh! That should be obvious. But if you think about a software company that has been around for 14 years, you'll realize that we are a group of people that has seen really wide range of technical innovations. So we just assumed (the wort possible word in our profession - as we learned once again) that most of our experience would translate to this new platform. We soon realized that although coding skills (e.g. Unity or C# skills) translate pretty well but as soon as you hit anything Ux be it GUI, interactions or usability you have to learn everything from scratch. The total immersion of VR and the closeness of that experience of that with everyday human experience leads to a complete rethinking of how the software should interact with the user. Mr. Cooper, a new About face is sorely needed.

Interfaces are your friend

I mean the Interface constructs the programming languages. VR hardware is still at infancy. Just like every other hardware race, several companies are fighting it out with their own set of hardware, SDKs and way of doing things (mostly bugs :) ). So the code you write needs to have a way to be abstracted easily so that you add new hardware support without rewriting the core game logic. And that's where all those OOP skills will come in handy. A simple rule we use is to keep asking "what if I switched to Rift here?" and that helps give perspective. So go for all the IPlayer, IScorePack, Ix you can think of!

Get early feedback

OK this is really ancient advice in software, but we felt that in VR software this is even more true than other spaces. Again, because of the closeness to everyday human experience and the immersion in a VR application (particularly a game with realistic graphics) it's very easy for users to assume they know exactly how (and where) things should be. Gone are the old escape routes that techies used to take like "Windows has their Cancel buttons there" or "right click is always context menu". As soon as we got our first broken version out we found that even team members were complaining about how a certain thing was being picked up or how a door was being opened. And it's obvious, these are things we have learned over years of real experience, there is a universally accepted convention out there for basic things like "picking up an object" and you cannot mess with it! So schedule demos at every point of the project, run usability sessions, even better run Joel's hallway tests at every opportunity you get. 

OK on that note let me leave with some of our "hallway tests" put together in a little video by our design guru.

I'll be sharing more of our VR development experience here, so watch this space!

5 Tools all non-technical software founders should use

Many software companies are run by founders who are non-technical themselves. As long as they have a technical team that is strong and reliable things work out just fine. However, there are some tools that the non-technical founders can use to make the software development process even smoother. These are tools that the techies themselves use but many founders shy away from them thinking of them as something that is "too techie". A little time investment on learning the basics of these tools could bring in huge improvement to how the software is made and delivered. These tools can save time and money by communicating early feed-backs and decisions in the software development process.

In our experience as a software development consultancy that has helped dozens of startups all over the world build out their products there are some tools that are absolutely vital for all the stakeholders to use - techies or non-techies. We insist that our customers use them, we even run training sessions for non-technical stakeholders to learn the tools. 

Today I'll run through my list of top 5 tools that every software project stakeholder should learn and use.

1. Issue Tracker

This is the easiest one to use. All software team use an issue tracker (or at least that is the least we can hope for). There are numerous very good trackers out there, what you choose depends on your taste and need. There is, for example, reliable workhorses like Jira or Fogbugz or super simple trello or if your team is all for mods - trac; the list is really endless here and it doesn't matter what the exact tracker is as long as it serves the team's need. Whichever tool they are using it's relatively simple to learn for a non-technical user and then start using it to stay in touch with what the development team is working on. The tracker is perfect for putting in early feedback on features, keeping track of what feature gets done when and to communicate with the developers within the context of particular tasks.

It is hard to list all the benefits of bringing in all the stakeholders to the issue tracker. It simplifies pretty much all conversations, takes away all the nasty surprises of product demos and brings in feedback at the right time of the development process.

2. Wire-framing tool

Wire-framing or mockup tools let you draw pictures of software screens in a quick and dirty way. They are essential to get a quick version of the software that can be used to communicate features, test if they meet the requirement and also check if users can use them. Usually the design team within a software group uses it to get the Ux done and rest of the group just uses the output for their work. But if a stakeholder can use the tool then she can quickly draw up her own screens or make modifications to the exiting ones without waiting for a designer to do it. This speeds up the whole communications channel and makes it really easy for complex ideas to be fleshed out.

I remember one project that we picked up midway where the founder would painstakingly write up huge documents to describe features that he and his team wanted to be built. These documents would take several meetings to be explained properly and even then misunderstood by a few in the team. Inevitably this created a lot of friction. We introduced a simple wire-framing tool to the founder's team and almost magically the whole process transformed to something that was simple and fun. 

My favorite tool is, of course, balsamiq which is just perfect for non-technical people. But there are many others out there although some can be quite daunting :)

 3. Build and deployment tool

A build system lets anyone create a build of the software from the latest code and deploy it on a "staging" where it can tried out. This has to be setup by the technical team and every self respecting software team should have one setup for even the smallest of software projects.

Once it's setup, it's relatively easy for a non-technical user to learn how to "get a build" done. Usually a few button clicks in the right places does the trick. But this gives immense power to the stakeholder as it lets her get a view of the software at any time without a lengthy process involving the technical team. Essential for quick feedbacks or a sneak peek or even a pre-launch demo to prospective customers.

Many tools out there for this. Jenkins and Cruise Control are popular ones and very simple to use once setup, but there are others that are equally good. 

4. Performance monitoring tools

There are many tools that can test the performance of a software. These are essential for quality assurance team to test the software but are equally useful to a non-technical founder to gauge the quality of the software that is being delivered. These tools can give the stakeholders a list of issues that they can then prioritize and push for fixes from the development team.

The tool(s) to use depends on the nature of the application being built. Usually a few google searches land you to the right pages, but here are some that have proved the test of time. An old but faithful tool for testing the quality and performance of any web application is ySlow it gives you a nice list of things that needs fixings to make the site faster and also points out glaring mistakes which may not be so glaring at all to a non-techie. Other examples in this genre are Google PageSpeed, WebPageTest, Page Analyzer and the full of bells and whistle GTMetrix.

Great tool to keep your dev team on their toes :)

5. Code quality tester tools

Now I'm in contentious territory! These tools analyzes the actual code and rates it for quality. It identifies obvious mistakes, not so obvious bad practices even performance flaws in the algorithm. A non-technical founder may find it impossible to judge the quality of the code himself but he can utilize these tools get an idea about the code. In many ways these tools can act like auditors for him.

Again this requires technical team to set things up properly. But once done the actual analysis is a simple process. It is definitely worth the time investment. At the bare minimum a non-technical founder should insist on having such tools installed on the development environment and ask the team to use them.

Once again, many providers, but only a few that are outstanding. The tool to use also depends on the technology platform e.g. in the Microsoft world Resharper or FxCop are very good tools. Java world has many (as usual) e.g. findbugs, PMD, etc. Whatever the platform there's a code analysis tool that is just a google search away!

// This article is a reprint from our CTO's LinkedIn pulse 

Reality of an augmented future

Augmented reality (AR) software has been around for quite some time, but it wasn't until the success of Pokemon Go that it really hit mainstream attention. Now everyone is looking at ways to incorporate AR into new applications across a wide range of industries. And there are compelling reasons for this.

AR technology provides a software application advantages that were just not possible in the past and in many applications it add huge value. Here are some basics of AR from the perspectives of software product owner which we advise our customers so that they consider incorporating AR into their applications.

Why add augmented reality to your app?

The user experience offered by AR is intuitive and easy to use, which makes it appealing to a wide variety of businesses. The UI elements appear within a particular context and help the user understand how to interact with it. There are some distinct advantages that AR offers, let me try going over some with examples to illustrate my point.

With AR you get a chance to leverage real-time data to enhance your software's functionality such as tracking a user's location and displaying information about nearby store locations. You get to combine visuals with expanded sources of information, which is a powerful combination for a wide range of use cases. 

Since AR is essentially a layer over what is right in front of you, it is an opportunity to mix the online virtual experiences with the real physical. Retail stores can give in-store customers quick and easy access to the same information they could look up online. For example, they can point their camera at a product and get a full description, reviews, a usage guide and more. 

The healthcare industry uses AR in many ways, such as a solution that visualizes veins for nurses. Patients are much happier when they don't have to get stuck with several needles for a blood draw or IV.

The transportation industry guides drivers into fixing and maintaining their own vehicles by providing guided instruction that walks the user through the entire process. They can stay on top of straightforward tasks, so the only time they need to be serviced is for more complex cases. 

Widespread AR adoption is still in its early stages, so many organizations are experimenting with ways to work augmented reality into their software. These initial offerings have many exciting features with the potential to change many industries. 

Your future software development projects should consider whether AR has a place in the application you're working on. In many cases, you get a big boost to the user experience and unique features that set you apart from the competition. 

7 best practices to know about before you outsource software

Say, you have the idea for a great app or you need to get your existing app updated. You are thinking of outsourcing the development because you don't want to manage a dev team or you just don't have the bandwidth with you current team.

So you think your next step is: start looking for a team. 

No it isn't.

Because even before you start looking for a software development partner you should know about the best practices for outsourcing software. Once you know about these you'll be much better armed to start the process and move it forward. Here is a quick list of the top seven best practice that anyone considering outsourcing should be aware of.

1. Know the reason(s) why you are outsourcing

Ask yourself "Do I really need to outsource?". Once you know the exact reasons and make a list of them for future reference. This will guide you through the process and make it easy to make decisions. Make sure that your software development project is appropriate for outsourcing. You benefit the most from this process when you need specialized expertise that you don't have in-house, need extra support for the project, or don't have the time to handle it yourself. 

2. Find the partner that is the right fit for you

Find an outsourcing partner that you trust with your project. You want a company with a great reputation that's known for delivering results. Check with your peers and read through reviews to determine whether they would be a good fit for your needs. But don't just stop at that point, what may be perfect for another company may not be right for you. See if the partner's work culture fits with your one, if their working times and communications matches your preference. 

3. Cost should never be the only reason 

Look beyond price during your selection process. You may be looking into software outsourcing as a cost-efficient option for your development needs, but you need to ensure that you end up with a quality product at the end of the project. 

4. Scope out your project well

Make sure you have a detailed document of the software you want to build. If you don't have that already use that scoping work as the trial project to test a potential partner. But whatever you do, provide a detailed project scope so everyone is on the same page with expectations. Have a procedure in place for handling any additional work that falls outside of this. You don't want to have a project endlessly delayed because you keep adding features and requests. 

5. Setup strong communications channels

Put strong communications channels in place so it's easy for you to reach out to the outsourced software developers and vice versa. You don't want poor communication to make the project take longer than it should or result in something that doesn't meet your original vision. Setup multiple channels but choose one as the preferred one. So you can have slack, emails, messengers, Skype, telephone, screensharing tools even issue trackers as the place to discuss but make sure everyone knows that one of them is the first place to try. 

6. Stay involved with the project

Stay involved with the development. Outsourcing doesn't let you simply wait until the outsourcing partner finishes the work, without any input on your part. Check-in with progress, find out if they need any resources from you to complete tasks, and take ownership of this process. 

7. Use a task management tool

You must use a project management or task management system to monitor development. It doesn't matter how simple your application is or how short your project is likely to be, you have to keep track of the tasks. You can get a good sense of the pace and whether certain tasks are stalling out your outsourced partner. 

Outsourcing software development is a valuable strategy to help you get your company's needs met. But it can go wrong very easily. This list is a start, but it is essential that you know this list well so that you can find the right partner and setup a process that can maximize your chances for success with the outsourcing. Also read our tips and tricks for selecting software vendors.

I was spoilt for choice when it came to selecting the Dilbert strip for this one. Dilbert's outsourcing land is of course Elbonia and there are many communications with the Elbonians. Here is a good one that goes pretty well with message of this article.

Have you considered virtual reality for your app? You should.

VR or virtual reality may not be as fancy or "game-like" or just too far away as you think. There are many use cases where VR can be used with great success in an everyday software!

What is it?

Virtual reality enables companies to simulate environments within their software. With these applications, users can experience a real environment without physically visiting the place or they can move around within an imaginary environment. So, for example, a person from across town, in another state, or even across the globe, can experience the environment, without leaving her couch! A Star Wars fan might find herself on a Star Destroyer or a Republic Cruise ship making decisions with the help of the Force – and a VR software.

Why should I consider it? 

The use of VR can be in many facets of a software application. Many of our customers shy away from VR saying that it's just too fancy or not a good fit for their business. But if you think about it a bit more you'll find many benefits using virtual reality where you'd think none existed. Here are some example areas where we have convinced our existing or new customers to re-think their applications and to leverage this upcoming technology: 

• Cost Savings: Rather than build training room or use much needed space, companies can build virtual class rooms that simulate their new employees’ work environment.  
• Real-Life Interactive Training: Human Resources use virtual reality software to build training modules that mimic specific scenarios, and employees can interact with these modules from a convenient location. Such training often keeps learners engaged and helps to build confidence.
• Experience a User’s Pains: "Remoting" in to a user’s work environtment for specialized help. VR software enables helpdesk attendants to simulate the user’s environment and get a clearer understanding of the way in which the current issues are impacting productivity.
• Help Customers Try before Buying: Businesses can use virtual reality software to give customers a 360-degree view of products. This helps customers select the most suitable product and reduces sales returns.

So, think again, adding a VR layer might solve many of the challenges in your application or bring in a completely new way of how your software adds value to your customers. If you want our help, we'd love to share our ideas! Give us a ping at info@kaz.com.bd

How to select a software vendor?

Let's face it, selecting a software vendor is not easy. There are just too many out there and it's very much like what you feel when you are looking at many brands of vaguely similar products in the supermarket and trying to decide which one to pick up! Today, I'll try go over some of some of the things we feel that you should consider before picking up your vendor.

When you select a software vendor or software developer, you don’t just commit to a piece of compiled code. You’re committing to a way of doing business. That software – if it’s the right tool for the job – could be something you and your employees use regularly for years. And if turns out to be a square peg in a round hole, you’re SOL, back to square one, repeating the same software search you thought you just finished.

With so much riding on your selection, how the heck do you do it right? How do you find that magical software vendor, custom development team, or SaaS provider that works for you?

Evaluate the Product

Almost everybody starts their vendor search by shooting a swarm of RFPs into the void and hoping that helps narrow things down. The problem with RFPs is that nobody wants to tell you that they can’t do something. Once your RFP process weeds out the folks who aren’t ready for your jelly, you can start actually finding out what solution will work.

At this stage, you should get some hands on time with their product or, if you’re scouting custom development, their previous products. Sit through a demo, then see if you can get your hands on a trial version or run a smaller project with them first.

Pick software like you’re Goldilocks: not too slim, not too robust. You want the feature set that’s just right. Plus, you’ll see how stable their work is, and avoid critical crashes during crunch time.

Evaluate the People

You aren’t just buying a software solution, you’re getting a vendor and all the people therein. Find out what their company culture looks like. This might be the single most important factor of all. You need a vendor that shares your vision of the business landscape. Do they operate on the same time schedules that you do? If your business runs an Agile shop dropping weekly updates, imagine how much of a hassle it’d be if your vendor only updates yearly.

The people you work with should be responsive enough to take care of your issue before they cost you money. Whether that’s support issues, implementation work, or feature requests, how your vendor communicates with you can make or break a relationship. And make no mistake, this is a relationship, so chemistry matters as much in business as it does in romance.

Evaluate the Partnership

Your software vendor will become pretty integral in your business operations, so you want to make sure they operate as your partner, not just as the guy who sold you something. Are they excited about your project? If you’re looking at an implementation or custom development process, this is incredibly important. Your vendor will play midwife to your product concept, so they should care about it enough not to drop your baby.

Make sure the pricing scheme they offer works for you. That might mean exploring alternate pricing structures – fixed price, hourly with or without a cap, monthly fees, etc. It’s in both your interests to set a price that works for everybody. Your success and your vendor’s success are linked; if one of you goes out of business, the other one gets hurt as well.

Choosing a vendor should be more than just ticking off features on a checklist. You need to review the whole partnership, including the people you’ll work with and the partner you’ll have. Remember, we succeed together and fail alone.

Oh, one last thing, consider us when you are searching for developers who will build your next great app. We are a small award winning software development company solely focused on helping our clients design and build their software products.