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. 

5 things every software development contract should have

Software projects are different from many other projects where a physical product is built. And hence there are some issues that a software development contract should address that are not very common is other contracts. Yes, like other contracts there would the usual suspects like commitments, warranties, liability, etc. But here are five not so common ones that our experience says are essential for a software contract.

1. Initiation Period

This allows both sides to disengage easily for a limited period of time after the start. This is essential because only when a project is started does it become apparent if the relationship is a workable one. A great software company with perfect skill set, gold plated credentials may turn out to be very bad at communicating ,for example. Similarly for a software company it may turn out that the client just can't agree on technology choices. Whatever it is, if there is no fit the project will fail or the process will be painful. This lack of fit becomes quite obvious very quickly. So the contract needs to take this risk into account.

Here is clause we commonly have in our contracts to cover for this initial period:

"The Parties agree that they shall commence the engagement with an initiation phase of six calendar weeks, commencing on the Effective Date of December 1, 3001. Acme inc. will provide services during the initiation phase, and BigShot inc. shall be liable for payment for such services. During the initiation phase, this agreement may be terminated with one calendar week’s notice; at the end of the initiation phase, the agreement shall enter into ..."

2. Change Requests

A software product is a moving target. You can have the world's best specification when you start but you'll end up with a software that is slightly different when you finish. This is normal. This is the way it should be. Because as the software interfaces are being built new requirements arise or old requirements change or die out. If development stays rigid and doesn't listen to these change requests the resulting software will not be good. So "embrace change" is the way to go. But, how do you setup a contract to cover this risk?

There is no single answer that fits all size. How you address this in the contract depends very much on the project. If the specification, for a project, is very good and detailed a wording that allows a certain percentage of change may work nice.  Here is an example:

... up to and including between 5 and 10% changes in any Work Product, order, and other goods and services that Acme inc. produces or designs under this Agreement at no additional cost... 

If the spec is not that clear then the above wording would be disastrous! Here is an example that just might work in those cases (this is what we have used in some projects):

 "...If the proposed change will, in the Developer's reasonable opinion, require a delay in the delivery of the Software or result in additional expense, then the Customer and the Developer shall confer to first determine whether the request is a Change Request or an Additional Feature Request. Where it is agreed that the request is a Change Request, the Customer may in that case elect to either
(a)    Withdraw its proposed change, or
(b)    Require the Developer to deliver the Software with the proposed change, subject to the delay or additional expense or both..."

3.  Software IP

This is an obvious one. So I won't spend time on this, but just mention something that sometimes is missed or not considered. In many projects the software developer might use a library or a component that it has built as a re-usable tool to be used over and over on client projects. The IP for such components belong to the developer but the contract wording should allow the customer to use it royalty free. Here is template that works nicely:

"...To the extent that developer uses any developer IP when providing Work Product for customer under this Agreement, developer grants customer a perpetual, irrevocable, royalty-free, non-exclusive license to perform, display, use, reproduce, modify, and adapt the developer IP, in any medium or form of communication now existing or hereafter developed, within the Work Product..."

4. Non-Competition

An inherent risk of employing a software development company to develop software is that they might also be hired in the future by a competitor or even worse make the software themselves. The contract needs to address this risk clearly with a non-competition wording somewhere. Here is an example:

 "..for a period of x years after the termination of this contract the developer shall not develop, reproduce, promote, distribute, market, license or sell any product or service that competes directly with the Work Product provided to customer, nor shall the developer enable any third party to compete directly with customer..."

5. Hiring Resources

The team that builds the software becomes experts of the system. If the software project becomes very successful the customer may want to retain certain members of the team. The software development company would obviously be worried about this. So this need to be clarified right from the beginning in the contract. Software resources are precious, so this is a delicate situation and finding the right balance is difficult. Here is a wording that is pretty fair:

"...customer may request developer to place named team members as direct customer employees, with the express prior written consent of developer. Developer shall be entitled to compensation for placement of such employees; the relevant compensation shall be discussed and agreed prior to any discussion of such placement with the employees concerned..." 

Disclaimer: I am not a lawyer. You should always seek professional legal advice when you are setting up a contract. 

As usual, I'll finish with a stolen cartoon from Dilbert. But to give something small back, have you read Scott's book "How to Fail at Almost Everything and Still Win Big: Kind of the Story of My Life"? If you haven't you should. Really good stuff. 

From idea to awesome - beginners guide to launching your app

Software development is a journey. Starting from an idea to a fully functioning product takes a lot of work. Involving a hand full of expertise, product development goes through phases in order for finished goods. It can be frustrating from time to time dealing with the stages of production, but a fun way to go through it is treat is a path full of challenges. Similar to those games where reaching the next levels provides a reward. Working with designers, programmers, software testers, etc. can also be educational to learn new buzz words, viewpoints, thinking. So here is how it goes:

Idea

Every software product starts with an idea, that can either be absent from the market or more to an existing solution. But the “IDEA” is the start for this journey.

You come to software developers like us  with an idea for a product that does not exist in the market. You typically speak to a "requirement analyst" (buzz word for anyone who understands software products well). You explain the features and the advantages of the product.

Sketches and features

From the discussion, we make notes of the functionality and make sketches of the product. We use the sketches to make a list of features for the product.

Wireframes

We then develop a wireframe for the product that details the functionality of the product. Wireframes are nothing but a slightly better set of sketches where you can follow how your app will behave. The wireframe pictures go through a lot of to and fro where you say "nah, I am not sure that's how I want it" and us saying "but if you don't make that action button large people will not tap it" etc.

Mockups

Once the we are all happy with the wireframes our designers turn the wireframes  into colored pictures of what the actual application will look like.  Designing mockups will help to visualize the outcome of the product, that will involve the colors, icons, identifying the different functional changes.

Development

Using the wireframes and the mockups, the programmers come in to play, the development phase starts.

Testing

Software testing will improve the product, fixes bugs and helps to do more before the release.

Launch

After all of these, when the product is ready, it will be launched to your end users.

Awesome!

Ending with customer(s) appreciating an awesome solution that they have been waiting for.
 
Now is this a brief explanation for the phases for a software development process. There are more to it when it comes to real life production process. Just try to think of it in a fun and simple way to deal with, makes the whole production process a lot easier, collaborative and efficient.

Saving the startup from burning up

The Problem

The biggest worry for any software startup owner is

Will I burn up my funds before I can get my products launched?

And this should, indeed, be her biggest worry. Great ideas are good, but if you cannot launch and get users, great ideas die out badly. It is absolutely essential to get something out quickly, get user feedback and pivot to the next step. If you can't then there is a very good chance that your startup will just "burn up".

A great article is around expected burn rates (in US) and what you should aim for is Burn rates: How much? by Fred Wilson. Here is a rule of thumb about burn rates from there:

...multiply the number of people on the team by $10k to get the monthly burn. That is not the number you pay an employee. That is the "fully burdended" cost of a person including rent and other related costs. 

And this was 2011. The figures are much higher these days for sure.

A Solution

A great solution to this burn up before launch problem is to use a development partner who can lower the costs of production. By having developers in low cost countries such as Bangladesh, Cambodia, Nepal, etc. it is possible to lower the costs without compromising on quality.

We are old hands in this start up and burn up drama. When we started in 2004 our first project was to help a silicon valley start up save themselves by finishing and launching a product they have been trying to build before they ran out of money. We made their remaining funds run a long way and got the product out within 6 months within budget. With that as our initiation, it is no wonder that we have helped more than 20 startups get their products out on their angel funding. Once the 1.0 product is out a start up can breath easy and see how user adoption and feedback is. Based on that they can decide to seek more funding or in the happy cases start making money!

For us, as a software company that thrives on ideas and innovation, working with the startups is the biggest fun. This gives us the chance to work on new technology, challenge ourselves with difficult technical hurdles and deadlines. 

We are so confident on getting the first versions out with angel funded startups that we are offering startups looking for dev partners in the CeBIT 2016  a "Launch under 10K Euro" offer. 

Interested? 

Meet us at CeBIT2016 or contact us to explore.

Learn More

Launch under 10K

Two ingredient recipe for a great software team

Great software teams are hard to define, yet they are very easy to recognize when you see one. There is energy, enthusiasm, excitement and everyone in such a team feels like they are on a mission. Things just get done and software launches feel robust and predictable.

Great, I need a dozen, but how do I create one?

Now that's a really hard question. We've spent a long time building software products and the teams behind them. And have managed to create a reputation for building great teams. So we get asked this question a lot. After answering numerous times at different levels of hand waviness we have come to realize that we can boil it all down to just a single a basic recipe with just two ingredients:

1. Gelling - how close the team members feel to each other and how strong they feel for the whole group.

2. Openness - how easy is it for team members to criticize each other or themselves or voice concerns without worrying about propriety.

The funny things about our recipe is the the exact measures of these ingredients don't matter. The more you have the better things will be!

There are many things you can do to get these ingredients into your team. You will need to experiment and see what works for your team. If you asked us to name just one thing that works (for us), we'd say it must be our: 

Team events

We arrange events where some kind of group activity is needed. I think it's essential for these events not to have the explicit feeling that it's a "corporate team building" event - that feeling makes the gelling less natural. We try to make the events fun but include some elements that necessitates the group's input.

A classic at Kaz is our yearly trip where the overall planning is left to the team to finalize. This gives the team to come together and work together to create fun for the entire team as well as their families (as families are welcome too in these trips). We intentionally leave some constraints, a shoestring budget is typically the a big one but also there could be others like "ensure that the kids are not bored". These restrictions make the team members think in terms of the whole team which is a big thing for gelling. 

Good luck with your team building efforts, but before leaving, here are some pictures from our recent trip to Nepal!

How to test a new outsourcing partner?

In the world of software development projects there are many ifs, buts and maybes. It's hard to find absolutes. It's next to impossible to give a formula for success. But I think at least the answer to the question "how should I test a new outsourcing partner?" is one of the rare cases where you can confidently say you know the absolute correct answer! It is equivocally:

Start with a small test project or a prototype building phase.

Here are some examples of this small project that we, at Kaz Software, have suggested, to our clients, to test us out!

• A test project - made up just like a test to try the new partners out. Ideally you should know what outcome you'd like so that you can judge (just like an exam) the result. Even consider doing this test internally with your team too, so that you can compare. 
• A tool that you needed built - this may be something thing you always needed but could never spare enough dev time with your team to do it. Say for example - a tool that helps HR generate some monthly reports. The tool should have some challenges that you want to check how the new team solves. Nice thing with a tool is that you probably will get a useful tool out of this testing period.
• A prototype - this is a really good approach for start-ups. Get the team to build a quick-n-dirty prototype of the actual application that you want them to build (at least a subset of it that is). This has the added benefit that you can judge how much they captured your specs and also lets you use the prototype for demos and future spec clarifications. And if you continue with that team the domain knowledge already picked up is really a big thing.
• Product design/ideation/brainstorming - this is probably the easiest one to try if you don't have the time for a more elaborate one. This should, at a minimum, be a week of meetings with project leads, designers and even developers just brainstorming what you want to build. Coming up with new features. Output should be at least wireframes of major use cases. Although it doesn't let you test coding skills, it lets you see how pro-active the team is and definitely lets you check out their culture. And the output itself is useful (hopefully).

Do you know which one you will like before trying it out? Only if society would allow a nibble before a committed pick? :( 

The gist of the problem is very similar to the problem you face when you have to choose a chocolate from a  new box. They all look pretty good, but until you try them out you don't know for sure that you'll like what you've picked. Sadly it's socially quite unacceptable to nibble a chocolate first and pick it up only if you like the first nibble. But happily this is very much a possibility in the world of software outsourcing!  

You can stop reading here. You don't need to know why doing a small project is the correct answer - I'm that sure about this bit! And we have a lot of experience here, working on outsourced projects from all over the world for the past twelve years! 

But if you are interested here are some explanations.

Lets you check for fit with a small cost.

When you embark on a software project with an external team you just don't know if there is a good fit between your team and theirs. Do they understand what you say (even if they speak the same language)? Do they prioritize the way you do? Does their culture fit with yours? Does your team like their culture? Do they use the tools that you want them to use? Do they use them the way you expect them?

Endless questions which can never be answered satisfactorily without working together. Yet these questions are vitally important for the end product. Fit is everything. Let me say it again, the single most important thing for a successful outsourced software project is fit. But you only learn about the exact nature of the fit deeper down in an engagement. When it may be too late to exit if you suddenly realize there is not enough fit.

Lets you extrapolate

The results of a small project lets you extrapolate and make projection of what the result of the real (bigger) project will be. The way a team manages a small project is in essence the same as the way it will manage a bigger one. If the culture is "get it done" or "analysis paralysis" or worse "random walk" you spot it right away - and you can be sure that the same will apply to your real project.

With the results of the small test project you can make much better informed decision about a outsourcing partner and then decide to commit or not to commit.

Lets you exit early if you need to

Obviously. And exiting early is very important when you know something will not work and you need to start from the beginning to find a new partner. Ideally you should have the backup candidate ready, or even better, if you can afford it, make them do the small project in parallel - which is what I'm calling A/B testing loaning the word from webpage optimization.  

Lets you run A/B testing 

If you can afford it, get competing partners to do the same project in parallel (without telling them you are doing it!). This then let's you compare the result and find the better candidate.

Another variation is to get your internal team to do it in parallel and see how your own is different from the  new partner. If you do this, consider doing a presentation/retrospective session where the external provider explains their decisions to your team and check how the debates go between teams where their solutions differ. Very useful to find how the teams will work together (and separately your own secret review of your team's performance thrown in for free). 

Lets you fix issues either for this team or for your next one

There will always be some issues that need fixing when you are going to work with an external software team. The test phase lets you identify them right away, so that you can have that as a to-do list when you start working on the real thing. 

Even if you don't eventually decide not to go with the team, this list tells you what to watch out for when you look for when you go back to selecting another partner.

OK, here is my find from Dilbert today. Btw, if you don't like Dilbert strip then maybe there would be a fit issue with us! But if you do like them and you have a software project that you want to get done by the experts (and want it done at a lower cost), give us a knock - even better give us a test project! We may even do the test project for free to show off our prowess :)

Back from my shameless self promotion here is the Dilbert that I promised!