Hope, confirmation bias and entrepreneurs

Entrepreneurs are often trapped in a vicious circle of hope.  Hope clouds judgement and can be what prevents the entrepreneur seeing things clearly and taking the appropriate decisions.  Hope is so seducing that it’s what is used in most personal development or “get rich in x lessons” books.  Hope is also so powerful and rewarding that it is fed by proofs generated by the confirmation bias, that is itself fueled by hope. Entrepreneurs must learn its underlying concepts and learn to get objective opinions from others.

Confirmation bias refers to a type of selective thinking whereby one tends to notice and to look for what confirms one’s beliefs, and to ignore, not look for, or undervalue the relevance of what contradicts one’s beliefs.  [Skeptics Dictionnary]

Before talking about confirmation bias, let’s understand what is hope from a psychological point of view.  Hope is one of the many mental defense mechanism we have that is triggered in order to disconnect us from hurtful emotions (anxiety, sadness, despair, ….).  It uses thoughts to construct a positive scenario of the future.  People often grab these thoughts as a life buoy to avoid the reality of the present moment. We usually hope for a better future when we are  uncomfortable with the present.  Hope is what drives many wantrepreneurs.  Hope will make entrepreneurship’s book writers rich, not you.  Happy people hope for the best, once, then stop thinking about it.

In order to fuel hope, you need proofs that what you see in the future is possible and is likely to happen. This is when the confirmation bias enters into action. Every single proof you see that makes your predictions credible is highlighted, while every single piece of evidence that it won’t is denied. Those proofs stimulate hope that itself forces you to suffer from the confirmation bias. It’s a vicious circle.  One great example of the relationship between hope and the confirmation bias is seen with believers of the 2012 end of world event.  They can point to you dozens of  scientific  studies that prove it will happen, ignoring the hundred other proofs that it won’t.  One seducing thought in the 2012 case is that the event can potentially make them better than they are now.  Hope is triggered by a desire for change and fueled by confirmation bias.  Desire for change is not the only way to trigger hope.  Any unwanted emotion, such as fear, can also be a very good motivator: some religions claim that if you are not a good practitioner, you won’t go to paradise, but burn in hell forever. With entrepreneurs the desire for change is the key to the process.

Hope & Confirmation Bias

Conscious thinking is not the only factor: things get worse when we take into consideration theories of biological psychology.  Desire to change is not the only motivator for hope. There is a physiological reward for the behavior. Dr. Robert Sapolsky, professor of biology and neurology at Stanford University conducted experiments that showed that there is a direct link between hope and dopamine (pleasure hormone) releases in the brain.  Studies even show that we get higher dopamine releases when there are more uncertainties. Uncertainties? That is certainly something that entrepreneurs can relate to.

The ability to cope with temporary difficulties is one of the entrepreneur’s required abilities. Too many people can’t go through what Seth Godin called The Dip.  Defeatism, the opposite of hope, is one of the obvious failure factors in entrepreneurship.  Often they decide to stop.  They think their efforts are not worth it anymore.  Defeatism works just like hope. Your judgment is biased and you see things from the negative side.  It is also fueled by the confirmation bias in the same way.

The Dip Illustration

Optimism is often suggested as a strategy to fight defeatism.  It’s true that if you tend to be defeatist, hope can counter balance the feeling by replacing negative thoughts by positive ones.  It’s positive psychology. And it’s even suggested by the Emotional Intelligence guru Daniel Goleman.

Having hope means that one will not  give in to overwhelming anxiety, a defeatist attitude, or  depression in the face of difficult challenges or setbacks. [Daniel Goleman]

Just as defeatism must be avoided, hope can’t be a strategy on the long term. It can even  hurt as much as defeatism.  Do you remember how you felt after you really hoped that something would happen and it did not? You would be really surprised if you noted each prediction you make and compare them with what actually happened.  Hope will play against you.  It will hurt, it will hide a more concrete problem, and more importantly, it will bias your judgment.

Self awareness, again, is the key. To manage the process, consider hope (or defeatism) as a signal you must decode by being aware of the physical and psychological mechanisms. If we suspect we are biased, we must not believe entirely what we think and assess every hypothesis we make with realistic information.  Market studies and/or customer development are ways to assess our assumptions, as well getting mentorships from more experienced people who have learnt the hard way. With some practice, you will be able to acquire the self awareness required to avoid being trapped in those loops. Be a mindful hacker.

 

 

If you know neither the competition nor yourself, you will fail

There are two common types of behavior I have noticed in people regarding their competition. You have the competition driven people, and the competition denial people .

The first constantly monitor their competitor’s activity by visiting their websites & forums or googling them constantly, while the latter meticulously try to avoid any piece of text mentioning their names.  Sometimes, the latter behaves like the former by accident, triggered by some source of information they have read by mistake… Both emotionally driven behaviors are very dangerous for their business.

A third widespread behavior, linked to the same concept, is to not enter a market because of the presence of one or more competitors or even worse, entering a market without studying the competition in detail. All these types of behavior will make your business decisions weaker. The solution is to take your competition for what it is, no more, no less and try to intelligently decode your emotions and thoughts (both are linked).

When someone is competition driven, he will often take any of the competition’s initiatives as something he doesn’t have (and therefore he must have), instead of taking it for what it is: an initiative that can be equally good or bad.  The resulting action is to try copying the competitor’s ideas (but perhaps doing them better…). The problem with that behavior is that the competition will always be significantly in advance and the market will inevitably perceive him as the follower, not the leader, constantly competing on basic stuff such as features & pricing.  It’s not only his innovation that will be affected, but his overall entrepreneur’s ability to take good decisions.  Being so abnormally obsessed by a competitor can be the start of very serious trouble possibly leading to burnout or worse, to the abandonment of the venture.  His fear of competition is irrational.  Many of his important decisions will be biased by his distorted perception of his challengers.  It’s not how he should develop a wealthy company.

Competition denial on the other hand, is the action of ignoring the competition completely. This is a very commonly suggested strategy to solve the results of competition driven behavior. That is, by ignoring anything the competition do, his judgment, innovation & decisions are not affected by what they are doing. After all, he may say, listening to the market and customers is the only valuable thing to do.  Instead of being competition driven, he becomes customer driven.  It’s a seducing way to drive your business, but ignoring the opponent can hurt you as much as being obsessed by them.

If you know the enemy and know yourself, you need not fear the result of a hundred battles.  If you know yourself but not the enemy, for every victory gained you will also suffer a defeat.  If you know neither the enemy nor yourself, you will succumb in every battle.

Sun Tzu, The Art Of War

This is something I learnt from practicing martial arts. Before an important fight, you must watch videos of your opponents previous battles (or previous fights in a competition).  Watch how he moves, what he is good at, what he sucks at.  It will helps you develop effective ways to attack him and defend yourself.  Strategy is not the only important thing in a battle.  Attitude can make all the difference.  If you have a very determined opponent in front of you, this will affect your morale during the battle, and therefore your performance.  Invest in strategy by analyzing the market, including competitors, and in self confidence.  The former will help your differentiation in the market.  The later will surely contribute to making your competitor fear you, leading them to one or both of the unwanted behaviors described in this post, and making you the leader. Maybe.

The actor–observer asymmetry

There is a difference of judgment in any activity depending if we are an actor or an observer (Malle, Knobe, Nelson 2007). I realized this fact when I was practicing martial arts, long before my studies in psychology. The audience, usually parents, downplayed the difficulty of the discipline and very often judged the activity incorrectly. One of the most common expressions was, “but it is only dancing.”

This comment annoyed many of the new practitioners, but not the more experienced who knew that this was a gross misjudgement. You could see the difference when these same people decided to try the discipline once. As you can imagine, most did not usually go beyond the first attempt as it was physically demanding and much more difficult than they had imagined. Their judgement of the activity observed radically changed when they became an actor.

In our everyday life, we alternate between the positions of observer and actor. In both situations, we make judgments and many of the various decisions we take are based on them. As an observer, we can judge incorrectly the behavior of others. As an actor, we take into account the judgment of observers. It is important to recognize these situations and act accordingly.

Let’s take a concrete example: starting a software business. This is a subject dear to my heart as I far too often watch the growing disillusions of entrepreneurs when they take in the reality of things. As the disillusionment grows, only those predisposed (very rare) or those working for pleasure keep going.

The reality is that entrepreneurs work very hard and take on tasks that we would probably never have agreed to do as an employee.  You must also be aware that very few projects succeed at first; most stop after the first failure.

When we see talented entrepreneurs in the newspapers, we think it’s easy and as simple as registering a domain name, writing 10 lines of code and then selling your company for millions. The reality is that most successful people have worked hard, often in physical and psychological pain, for many years and have faced all kinds of problems. They made the difference by persevering. All my successes have been preceded by hard work and pain.

It is difficult to realize this when you have not been there yourself. But how do you know before you make a judgement or take an important decision?

The first step is certainly to become aware of any bias and take it into account. It is very difficult as these behaviors are unconscious and judgment is rooted in how we operate.

When you realize that you are in an observer’s position and about to judge and eventually take a decision, you should not be satisfied with the information available. As you may have noticed, observing is insufficient to get an opinion, even if one is aware of the bias. Failing testing it yourself (and you can’t start a business as a test in the same way you can attend a single martial art class), the only solution is to ask questions of the actors. Those who have experience in the field or are in the situation. Do not just question one of them. The more people you question, the more relevant your information.

The only concern with this approach is that it can block you from moving forward. Indeed, if you ask too many questions you can start to stagnate. Everyone now knows that one of the primary qualities of an entrepreneur is his ability to move forward quickly. Many are also characterized by a certain impulsive trait which will be discussed in a future article.

Awareness of the actor / observer asymmetry is directly related to critical thinking: identifying biases, separating fact from opinion and analyzing data. Awareness of our mental functioning is, again, the key.

8 reasons why you shouldn’t rely on source lines of code as a software metric

The estimate of the value of production of software based on the number of lines of code (LOC or KLOC or SLOC) is as popular as it is controversial. The main criticism is that there are too many factors influencing the final measurement value. Robert E. Park (1992, page 140), software metrics specialist & staunch defender of the method, responded to critics with the following:

“When we hear criticism of SLOC as a software measure, we are reminded of a perhaps apocryphal story about a ditch digger who, when asked one day how he was doing, replied, “Dug seventeen feet of ditch today.” He didn’t bother to say how wide or how deep, how rocky or impenetrable the soil, how obstructed it was with roots, or even how limited he was by the tools he was using. Yet his answer conveyed information to his questioner. It conveyed even more information, we suspect, to his boss, for it gave him a firm measure to use as a basis for estimating time and cost and time to completion.”

Originally, this technique could probably be used in the conditions mentioned by the Park. Later models such as COCOMO (Boehm 1981) also allowed developers take into account a number of parameters whose variability was probably reasonable at the time. But since then, the number of factors affecting the number of lines of code has become so important that it is very unwise to take this action seriously both in the evaluation of the software and the productivity of the design team.  I will try to illustrate the problem using eight arguments.

1. Different languages and different frameworks

Today hundreds of different languages exist (Wikipedia 2013).  For each of these languages there are several frameworks.  For the same functionality, there may be a very different number of lines of code produced depending on which technology is chosen.  In addition, modern architectures use different technologies, which further complicates calculations. Correction factors exist but they hardly seem defensible given the wide variety of types of applications that are being developed today.

2. Experience and competence of the developers

We must also take into account the experience of the developers involved as this may affect the calculation in many ways. A very competent developer often writes fewer lines of code than other less experienced developers because they will use design methods created for the sole purpose of reducing the number of lines and increasing readability and maintainability. In addition, they are more competent with the functionalities offered by tools (technology stack). Indeed, through ignorance of these, many programmers rewrite existing code, greatly increasing the number of lines of code.  In this regard, many experts in the area do not hesitate to speak of “lines of code spent” as opposed to “lines of code produced” (Dijkstra 1983).

3. The practice of refactoring

The fact that the same piece of code can change over time with the refactoring (reworking of code) can skew the results. This practice reworks the source code without adding functionality (Wikipedia 2013) and it is becoming more common because it can increase code quality and reduce technical debt. This can cause unexpected situations: if many developers practice this technique while the lines of code are being measured, the result could give the appearance of a reduction in output (fewer lines of code than in the previous measurement), while it is clear that the opposite occurs.

4. The practice of reuse and / or code generation

The reuse of existing code is very common and highly recommended in DRY (Do not Repeat Yourself). So many parts of the code can be retrieved from a previous project or copied from an open source project, library or another blog post. In addition, modern development tools can automatically generate code for the developer who works with various high level design tools.

5.  Tasks outside development

Activity in the development of software is not limited to writing code on a keyboard. In fact, many other tasks are needed to produce quality code. Here, a high variability can emerge according to the different methods used, the composition of the team or the documentation requirements.

6. The reliability of the measurement tool

A wide variety of measurement tools are available on the market. Given the lack of consensus on the method of counting the amount of lines of code in a source file, the outcome may be materially different depending on the tool used.  In addition, certain technical problems can arise when it comes to identifying what should actually be counted or not. For example, some software has difficulty differentiating comments from instructions when they are mixed (Danial 2013). The efficiency and quality of those source line counter is also very variable.

7. The (potential) manipulations

When a measure may have an impact on one or more person, we need to consider the possibility that some of them try to manipulate it to their advantage. Thus, if the productivity of a developer is measured based on the number of lines of code (or functions), they could very easily manipulate the source code to inflate the results. This problem is very common in companies that use KPIs to conduct assessments of their employees. One can also easily imagine a company trying to maximise the numbers if they know they will be evaluated based on this metric.

8. Time

Almost all the above elements are time sensitive. For example, the competence of a developer does change with practice (this includes the famous learning curve). More features of languages ​​and frameworks are also evolving to increase the productivity of the developers. The longer a project takes, the longer the measurement will be sensitive to this bias

Conclusion

In conclusion we can say that estimating the production effort or value of a program using this software metric is very risky. However, this technique is widely used. Some estimate experts such as Steve McConnell (2006) are very aware of the ineffectiveness of the method but still use it in the absence of anything better. Other methods based on “function point” (business functionality) have attempted to resolve some of the issues addressed above, but the values ​​remain highly correlated with the number of lines of code (Albrecht 1983).  For me, the information obtained by these metrics, and anything based on them, should never be considered as reliable and should be used with great caution in your decision making process.

Note: Some of the information in this text come from the fruit of the research I have done for LIEU (Liaison Entreprises-Universités) a network of valorisation units of Universities and colleges of the Wallonia-Brussels federation.

References

Albrecht, A. (1983). Software Function, Source Lines of Code, and Development Effort Estimation. http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=1703110&searchWithin%3Dp_Authors%3A.QT.Albrecht%2C+%2FA%2F.J..QT.%26searchWithin%3Dp_Author_Ids%3A37850740200

Boehm, B. W. (1981). Software Engineering Economics.  Englewood Cliffs, NJ. http://userfs.cec.wustl.edu/~cse528/Boehm-SE-Economics.pdf

Danial, A. (2013). CLOC Limitations. Retrieved the 2 august 2013 from http://cloc.sourceforge.net/#Limitations

Dijkstra, E. W. (1983). The fruit of misunderstanding. Retrieved the 2 august 2013 from http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD854.html

List of programming languages. (2013, July 30). In Wikipedia, The Free Encyclopedia. Retrieved 12:48, August 2, 2013, from http://en.wikipedia.org/w/index.php?title=List_of_programming_languages&oldid=566431816

McConnell, S. (2006). Software Estimation : Demystifying the Black Art.Microsoft Press. http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351/

Park, R. E. (1992). Software Size Measurement : A Framework for Counting Source Statements. http://www.sei.cmu.edu/reports/92tr020.pdf

Réusinage de code. (2013, juillet 5). Wikipédia, l’encyclopédie libre. Retrieved the 12:04, august 2, 2013 from  http://fr.wikipedia.org/w/index.php?title=R%C3%A9usinage_de_code&oldid=94719037

Why the sprint review is important to developers

The sprint review meeting is crucial for you, the developer, because this is the time you will be able to both give a lot of visibility to what you are doing and also get the feedback necessary to better align your work on the real needs of customer and or users. Yet too often, this meeting does not achieve these objectives because it has been badly prepared.

Show what you have done

I would like to draw your attention to two of the main problems that may be encountered.

Firstly, showing the result of work that has no user interface, and then secondly making sure you show something that works.

For the first point, the difficulty intensifies when you are dealing with people who have never been programmers. They often do not realize that a developer can sometimes work for weeks for minimal changes to the user interface. In other words, they can hear what you have to tell them, but they cannot see it. The solution developers choose far too often is just not talk about it.  If you can’t demonstrate it – don’t show it.

This attitude is typical of personalities we technicians have.  It is undesirable because you cannot then get the views of your user on the progress.  Their understanding and view is much more important than yours.  You are first and foremost in their service, and not the reverse. Developers who comprehend this have a very significant advantage over others.

The best way to show something that will not be obvious in the user interface is to use a presentation slide that describes the change. Because every time you develop software it is supposed to add value, you must find a way to highlight it. Some examples:

  • For performance improvements, clearly indicate the gain in a metric understood by the user.
  • If you have completed some intensive code refactoring, you should be able to demonstrate the usefulness of the work by using metrics highlighting the reduction of complexity, testability, or other value that will in the long term give significant savings in maintaining the code.
  • For the functions for which it is impossible to show something, such as support for a new source of information in a communication tool, do not settle for spending a few moments going through an a list of work done. Describe the challenges you encountered – this should give them the context that they lack.

In any case you should avoid sounding as if you are just justifying the time you have spent on the work.  The idea here is to evidence that you have progressed and that you are in control of the situation.

One last thing about the demonstration: Make sure you do the following things:

  • draft a scenario that you will repeat to your users.  You must not just randomly chat about the project
  • This scenario should cover most of the needs expressed by the client. This makes sure you are not interrupted by constant questions during the demonstration. In addition, this will allow you to ensure good feedback (we will cover this again below).
  • Run the demonstration several times on the machine that will be used during sprint review. This should eliminate most problems.
  • Rehearse it once or twice under the same conditions as the meeting. That is to say physically in the room with the same equipment.
Collect feedback

Great developers excel in this task. They know that developers who give the most satisfaction to their users or customers are those who understand and realize the things that bring their customers the most value. This type of profile is very rare and it is again very difficult for a technician to fully grasp this concept.

Everyone knows that the users are usually more comfortable when describing their problems than with finding solutions. There must be a real interaction between the technician who will eventually devise the solution and the person who has the problem. For this interaction to be productive, the programmer should be able to ask the right questions and discuss areas for improvement – and this is especially true during sprint reviews.

Many developers fear this time because they are likely to be criticized. This particularly affects perfectionists. Here are some tips to manage any negative reviews:

  • Be aware that criticism of your work is primarily criticism of the latter – the work, and it would be inappropriate to assume that the customer is actually criticizing you.
  • Remember that criticism relates mainly to the person who has made it and how they have interpreted the situation.

Having considered the two points above, we must consider every criticism as an opportunity for improvement.

Of course, all this also applies to positive feedback and I will write an article soon that will cover this in detail.

To summarize:

  • You can show your progress and all your activities
  • Feedback is an opportunity for you to excel in your profession

6 advantages to using third party libraries over developing your own

You should always consider using existing software components instead of developing your own; even if you think that the latter would be much better. Here are 6 reasons why working with third party projects (open source or commercial) is usually a better choice:

Domain expertise: Authors are usually experts in the domain covered by the library.  This will ensure that you will get the most appropriate implementation.  A good example is SharpMap.  The main committers are experts in geospacial software.

– Stability: These libraries have the big advantage of being used by other people as well as you, and in many cases, hundreds if not many thousands of developers worldwide.  Most of the early problems have already been encountered by others and fixed by authors.  If they don’t fix them, it’s a good opportunity for you to contribute and give back to the community!

– Knowledge: You will learn from others’ code and design. Many popular libraries are written by top notch developers and are usually great examples of good coding practices and design.  You will learn by just using them.

– Finance: You save tons of money.  The equivalent of hundreds if not thousands of man days of work for free or, at the very worst, the cost of one man day for commercial libraries.

– Support: Paid libraries usually come with free support from top class developers that you can contact 24h a day.  Many developers of free libraries also provide that level of support.  Exposing your team to these developers will be beneficial for them.

– New features: They will appear automatically, without effort, in your product.  If you are using the reporting engine from vendor X, and vendor X releases the new feature Y, you will be able to provide the new Y feature to your customer at no cost, with very low effort.  You can consider the authors of your libraries as other teams working for you, for free or for very little money!

So, assuming that you are not an expert in the domain, don’t have thousands of users, have lots to learn from others, don’t have tons of money, will probably need support and resources are stretched, don’t reinvent the wheel.  Unless you plan on learning more about the wheel.

Do you think NASA would have been able to send men to the moon if they tried to build the components of their rocket themselves?

Incoming search terms:
  • using third party library disadvantages

10 tips to manage outsourced software projects

First a few words about the idea of offshoring. Many developers think offshoring is a threat to their job. I can tell you right now that if you can potentially be replaced by an offshore developer, then yes, you have a big problem. You are just a developer. Being just a developer can get you replaced fairly quickly, even by another local developer. To avoid being replaced you must become a problem solver: a problem solver whose specialty is software development.

This post is not about the potential threat of offshoring for your job, so if you are particularly concerned by that, keep reading this blog, I have few articles directly related to developer job security coming.  Meanwhile, you can check existing content that covers the subject. A few years ago, Chad Fowler wrote a book called My Job Went to India: 52 Ways to Save Your Job, later renamed The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life). I highly suggest you purchase the book as it summarizes it pretty well.

The advantages of outsourcing

There are several advantages for local development teams in outsourcing a part of their software projects.

  • You have access to talent worldwide: given the difficulty for western countries to find skills locally, access to talent worldwide is a real asset. There are tons of great developers out there waiting to provide you the best.
  • Cost controlled to the cent: outsourced projects can be started and stopped very quickly.
  • Highly scalable: because of the availability of the skills out there, it’s very easy to scale up.
  • Empower your local team: if you use outsourcing to empower your local team instead of trying to replace it, you’ll get best results.
  • You contribute to a better world: a developer you hire in India is able to support a whole family alone with only one salary. If you pay him the same rate as in your own country (which I do often when I’m financially able to), a whole village can be supported.

The only potential disadvantages are directly related to the way you manage them. Over the past 10 years I have outsourced up to 400 projects with hundreds of different providers spread over all 5 continents. Here are the 10 core principles that allowed me to reach almost 100% success rate with my recent outsourced projects. These 10 principles are divided into 3 categories: choice, supervision & strategy.

Choice

Choice is about picking the right guys. Choice is very important and you should spend time on it.

1. Avoid lowest & highest bidders

The potential problem you may encounter with lowest bidders is obvious. When asked what he thought about as he sat atop the Redstone rocket, waiting for liftoff, Alan Shepard answered “The fact every part of this ship was built by the low bidder”.  What about the highest ones? It seems that there is some correlation between bid amount and quality of the deliverable you will get. However, I found that in most cases, quality was high enough with average bidders and therefore selecting highest bidders would be a total waste of your project budget.

2. Check ratings

Offshoring platforms often give you the rating of previously completed jobs. That information should be taken seriously and used to make your choice. You wouldn’t hire anyone without checking with his 2 or 3 previous bosses right?  On a rating scale of 10, I usually discard any bid with a rating under 9 as well as bidders without any rating yet. Sometimes, I forget this rule for very small project so I can help new providers to get their first rating.

3. Prioritize motivation

Many bidders bid without reading your specifications carefully. I know this because I have posted absurd or incomplete specifications in the past (by mistake) and very few bidders actually reported it. Now I read all cover letters carefully and give more credit to those who actually write about the project itself. Some bidders will write about possible solutions to your problem and others will actually discuss how they will implement it. In practice, I have observed that the most motivated ones tend to perform better than the others.

Supervision

4. Protect your intellectual property

Seems obvious right?  But still, that’s one of the most common mistakes as most of us completely forget it. Things can go bad and the company you hired for the project can claim full ownership of their work. Or worse, they decide to use what you paid for in their own businesses. Ensure that a proper NDA and intellectual property rights assignment is signed. Most offshoring platforms provide that by default, but if you plan to go alone with no support, this is something you must handle yourself and require before starting work.

5. Refuse custom frameworks

Very often the developers or company you hire decide to use a custom framework or library they have written. Verify it is acceptable to you. Sometimes the development shop will give you full rights on the code they wrote specifically for you but not for their libraries. This is problematic. You have a huge problem if you are so dependent on them that changing trivial things in the application requires you to hire the same development shop. It’s not only about legal stuff, but also the potential complexity of the code that they wrote that makes it impossible for the standard developer to understand. Keeping the potential to continue your project without them is a really important choice that you will want to keep.

6. Impose standards

Make sure that they use standards in the technology of choice. Even if they don’t use specific custom libraries (see previous point), you may face another problem: a specific way of coding that doesn’t meet industry standards and globally accepted guidelines. In the worst case, you could be forced to rewrite everything from scratch to make any maintenance possible. I tend to give priority to main stream technologies for that reason. PHP or .NET for instance, depending on the project I outsource.

7. Review early, review often

You don’t want to discover at the end of the project the code did not meet your quality standards, eg missing comments, missing or poor documentation, poor coding practices, etc. Reviewing the work frequently will allow you to give feedback early in the development phase. Reviewing frequently is also the most effective way to adjust any misunderstandings of your specifications. Each review gives you the opportunity to clarify requirements.

In addition to requesting frequent demonstrations, require access to the repository. If this is not possible, request that you are sent the full source every week for review.

 

Strategy

8. Test providers with small projects

Before I give a bigger project to a provider, I test them with one or two smaller ones. I also try to give specific projects to specific providers that have performed well in the past on similar stuff. For example, I outsourced few web design jobs to a provider through a well known offshoring platform and now I work with him directly by email because I know he will perform really well.

9. Accept multiple bidders to reduce risk

For critical projects, I select two or three bidders then I take the best implementation. This works best with very small projects (under $5000). It takes more of your time but it is sometimes required. It was with this approach that I discovered that bidders with motivated content perform better than others.

For bigger projects, you can use a combination of the point 8 and this one: you test multiple bidders with a small chunk of your big project and see which one performs the best.

10. Assemble components

Another way to reduce risk is to outsource components that your core team can assemble locally. One advantage of this approach is that you can easily switch between providers and no one really gets access to the whole thing (reduce intellectual property risks).  But the most underrated benefit of this approach is that your architects are then obliged to develop an open architecture that will help you extend the application or replace whole parts of it painlessly in the future.

Final thoughts

Applying these principles alone is not enough. You will need to fail a few times to really learn what can be written in a simple blog post. Experience gained by practice is the only way to success. Don’t get discouraged if your first 2 offshoring projects fail. Offshoring empowers thousands of teams worldwide and you can do it too.

Scrum in ten slides

When I needed to do presentations of Scrum to executives and students, I started to look for existing ones. Most presentations I found were very good for detailed presentations or training. But what I was looking for was a presentation I could give in less than 15 minutes (or more if I wanted). Most of them also contained out dated content. For example, the latest changes in the Scrum framework were not present and what has been removed was still there.

I decided to start over and created a new presentation with the following objectives:

  • Based on the official Scrum Guide: the structure is very similar and I attempted to extract only the essentials.
  • Not more than 10 slides (without the front and back cover).
  • The least text possible to extend the possibility for the presenter to say what is important to his organization without missing the core principles of Scrum.
  • Having good visuals to make it attractive.
  • A final invitation to read the official Scrum Guide for those who wanted more detailed information.

The result is a ten slide presentation that you can download then use as a powerpoint by clicking on the button below. Images are also available so you can use another presentation tool. It is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License (commercial usage & sharing allowed & encouraged). Feedback & suggestions welcome in the comments of this post.

 

Download

Here are the slides preview:

Scrum In Ten Slides

Scrum In Ten Slides

Scrum Overview

Scrum Overview

The Product Owner

The Product Owner

 

The Scrum Master

The Scrum Master

The development Team

The development Team

The Product Backlog

The Product Backlog

The Definition of Done

The Definition of Done

The Sprint Planning

The Sprint Planning

The Daily Scrum

The Daily Scrum

The Sprint Review

The Sprint Review

The Sprint Retrospective

The Sprint Retrospective

Further Reading

Further Reading

 

 

Incoming search terms:
  • scrum presentation
  • developer team scrum
  • presentation on scrum
  • scrum agile slides
  • scrum in ten slides
  • scrum overview presentation
  • scrum slides

7 telecommuting tips for developers

Working from home or a private office is probably the future of knowledge age companies. It allows you to do away with commuting completely and to work in a quiet  and non (over) interrupted environment (if you decide to).  It’s the opposite of the open space office. The gain in productivity can be huge.  Both you and your (smart) boss are potential winners in the deal, not to mention the potential real estate saving for the latter.

Unfortunately, telecommuting is not for everyone though and this may be why it is not generalized yet despite the positive conclusions of the studies on the subject.  Procrastinators may find it very difficult stay as productive as they are at the office. You will also need lot of independence and self confidence.  Some employees may also suffer from isolation.

Procrastination and isolation are the two problems I will address in this post. Other problems related to telecommuting won’t be debated here such as:

  • security concerns,
  • the fact that telecommuters are less likely to be promoted (Kreitner & Kinicki, 2009),
  • potential loss of thrust by managers
  • communication problems with your team

Here are the 7 things I strongly suggest you to try.  I have experimented with this myself during the past 10 years. They provide some tips to help avoid both procrastination and isolation. Disclaimer: you may adapt them to your particular case and not take those empirical & personal observations as a generalization of what to do. I really encourage you to share your own experiences on the subject in the comments.

Procrastination

1. Use a schedule – as if you were in a formal office.

If you don’t do so, you will be tempted to work too much or too little, depending on your personality. Both are problematic long term. Having a fixed schedule will not only create some sort of rule to manage your time, but also help you beat procrastination.

One of the keys to beat procrastination is to have “starters” and avoid “retarders”.  If you like to do non work related stuff such as reading news or browse internet, reserve 30 minutes before and after your fixed work time for it.  When you feel the need to do it while you are into your work time, remember you will be able to do it after.  It usually calms down the need for it and after some some time, the addiction will disapear.  When you arrive at your work time schedule, close everything and start working. This can be hard the  first few (ten) times, then after a while the habit will kick in.

In order to avoid the frustration of having to leave off work in a middle of something, I try not to start debugging or another task that has unpredictable time duration at the end of the afternoon.

2. Replace commuting by physical excercises and meditation/relaxation.

Telecommuting will free up a lot of time, and you should take it as an opportunity to take care of yourself, and certainly not work more for the same salary. Consider taking up physical excercies and relaxation or meditation. It will improve your overall productivity and will contribute to reducing procrastination (Davis & Jones, 2007).

3. Take regular breaks

Since you don’t have your environment anymore to remind you it’s time to take a pause, use the pomodoro technique. I personnaly taking a break of 10 minutes every 45 minutes, but you may setup your own schedule. I use a special software for that called Workrave that I warmly recommend to you.

The pause can be either doing nothing (it’s what I do every other break) and free your mind or do stuff off your computer such as class papers or call a colleague.  In any case, this should occur in another room, and certainly not in front of a computer.  I personally do three minutes of mindfulness or simple observation of what is happening outside (simply being in the present moment).  Feel free to adapt this to what works best for you.

At noon, take a full break and don’t eat in front of your computer.  Some of you may enjoy some cooking time while others may be very relaxed by some time listening to music.

4. Put clear limits between work and your normal life.

This means you have a dedicated office/room you don’t use for your pleasure but only work.  This is very important especially if you have kids.  Your office should not be used to anything else than working. This also means:

  • don’t work on your laptop when you are watching a movie with your family
  • avoid any professional activities during the weekend
  • remove all work thinking and be 100% mentally available for your well beloved
Isolation

5. Go to lunch outside.

< Isolation is the other major inconvenience to combat if you are affected by it. To avoid isolation a great solution is to integrate a social lunch with others. Try to do this at least once a week.  Even if not with someone else, try to go outside at noon somewhere there are other people.  Why not with other telecommuters?

6. Do co-working.

Co-working is the new trend that involves a shared working environment for people even if they have independent activity. It feels like your office, but it’s not. To make this work, the co-work area must be close to your home.

7. Don’t telecommute every work day.

If you telecommute every work day, you will progressively become more and more disconnected from your company’s culture and people.  It’s inevitable and it will happen.  Be sure to dedicate one or two days on site.  When on site, go to lunch with your colleagues.

 

The Agile Essentials Checklist

Here a “light” Agile Software Development checklist that I have used for many years to introduce Agile in organization. I usually introduce few items per week.

Product Management
  • A product Backlog, estimated and prioritized by a “Product Owner” is used
  • A “Release Plan” exists and is known by the team
  • A “Company Strategy” exists and is known by the team
  • Features are divided into “User Stories”
  • The “User Stories” are estimated by the whole team using “Planning Poker”
Workflow
  • The development work is divided into iterations or timeboxed “Sprints” or “Iterations”
  • A “kanban” or “Information Radiator” is used
  • The tasks are not assigned, the team organizes itself
  • The “Velocity” of the team is known
  • No outsider can interfere directly with the team during an iteration
  • “Daily Meetings” take place and do not last more than 10 minutes
  • A “Sprint Review” is organized and the output recorded
  • A demonstration is held at the end of each iteration
  • The problems are tracked and by the “Scrum Master” and/or management
  • A proper Retrospective is held
  • A “Burndown” graph is updated daily
  • The “Code Reviews” are systematically organized
Development Tools & Rules
  • A source controller is in place
  • A continuous integration build server is used and testing (unit & guidelines) takes place at each commit
  • The packaging of the product is fully automated
  • A (simple) bug management tool is used
  • Each bug is reproduced in a single test and then corrected
  • 80% of the code is covered by automated testing
  • A “Solution Log” in WIKI form is used
  • The “Coding Guidelines” are defined and understood by all
  • A maximum of 40 work hours per week!

Please note that any numbers above can be adjusted to your reality.