Tag Archives: Competition

What’s Really Important – Collaboration

Well, here is day 5, on my What is Really Important? series. Once I finish this post I will be half way there. Good thing too – only a few days left before the end of the year and I promised myself I would get all of these posts written before January 1, 2010. I’ve got my work cut out for me.

There are all different types of collaboration and anti-collaboration (is that really a word? doubt it!) that can occur in a company. Some companies are really good at one kind, but really bad at the others. It is really unusual to find an organization that is good at all of them.

Here are the types of collaboration that I find to be very important.

Internal Collaboration

  • Team -This type of collaboration is the easiest to achieve. This typically is a group that is working on a project together. If these people aren’t working together well, nobody is going to succeed. Here it is clearly in one’s best interests to put the needs of the team first, because they strongly correlate with one’s own. Sometime you’ll get someone who tries to make their team look bad so that they come off looking like the hero who saved the project. That person is likely to get shunned and to get a reputation that they are difficult to work with over time.
  • Hierarchical or Vertical -A lot of people forget this one, but it clearly exists. This is collaboration up and down the management chain. This is different than command and control where an order comes down from on high and everyone follows it. We all know that typically doesn’t work. People may follow it, but they won’t own it. Vertical collaboration has people at all levels of the organization taking responsibility for future direction and decision making and it requires a significant amount of trust.
  • Cross Department or Horizontal - Most people think of this one when collaboration goes bad. This happens when you have team silos and instead of looking out for the organization as a whole, the teams are only looking out for themselves. This is insidious and hard to break, especially when team goals make up a large portion of a person’s performance review or bonus structure. Here you find managers hoarding resources (people, equipment, money) in order to have their team succeed. What typically allows these types of silos to be broken down is a set of corporate wide priorities. If your team is working on priority #4 and someone at priority #1 needs help – you better provide those resources so that the company as a whole is able to deliver.
  • Cross Cultural or Geographic - In the world of offshoring and outsourcing this type of collaboration is necessary, but it also is fraught with issues. People are afraid to collaborate in this way because they fear losing their jobs. In many companies this is a definite possibility, but this is a management stance. Being able to collaborate with people from other cultures and in other time zones is a skill. It is a valuable one. One is always better off learning this skill and taking it elsewhere than worrying about losing one’s job because of it. As our economy grows more and more global this ability will be essential

External Collaboration

  • Customer - Working closely with customers is important to the livelihood of any company. If you don’t provide good customer support and your competitors do, you are dead. Key customers should also be asked for their input, this is key for prioritizing new product capabilities.
  • Vendor - On the flip side, as a customer, you should strive to have a strong collaborative relationship with your key vendors. The bigger a customer that you are, the easier this is. However, many companies are looking to learn from their customers who are really pushing the envelope in how they are using the vendor’s products. Many times the most creative customers aren’t necessarily the biggest ones. Wouldn’t you like to drive requirements that you need into your vendor’s product development roadmap?
  • Partner - Lastly, you must consider companies that aren’t necessarily your customers or your vendors but whose products are complimentary to your own. Is there a way that you can resell each others products to have a more compelling offering? Is there a way that you can integrate the inner workings of your products so that when they are used together it is seamless? This is called a partnership because it benefits both parties equally.

What Can Development Do To Improve Software Quality?

Well, this topic is a little bit more technical than my usual postings. I recently had an e-mail exchange with someone on this topic and decided that it could make a pretty good post as well. Senior management can drive significant improvements in software quality by encouraging certain practices and behaviors in a development organization. Sometimes this means changing the culture of the organization to see problems as an opportunity to improve rather than an opportunity to initiate a witch hunt.

In a dysfunctional development culture software bugs are seen as failures that should not occur and should be hidden at all costs. Development teams and test teams are adversaries – fighting over the differences between designating a problem as just a “user error” vs an actual problem in the code. The worst instance of this that I have ever seen is a developer arguing that there wasn’t a problem – the code was working as designed. Nevermind that the design as it currently stood was something that would cause the customer untold amount of pain in order to work around. You’re supposed to test to the design right? No – actually you’re supposed to test based on the requirements.

First off, the team has to determine the best ways to find problems as early as possible in the development process – and with the least amount of manual effort. The concept of continuous integration is key here. Every time a programmer checks in a software change it should initiate an incremental product build automatically. This incremental build then should also kick off a base set of regression test cases to test the software functionality. BAM! The problem will be identified before a full build gets done at night *AND* you know exactly which check in to the source code repository caused it. This is awesome. It is easy to fix a problem if you know exactly where to look. If you wait a week or two to do a build you are looking through possibly hundreds of checkins to identify possible candidates that could have caused the failure. Now, granted sometimes this means that the change has to be backed out in order to do some serious refactoring. However, better to do this now rather than during system test. Full nightly builds are also crucial. Sometimes two independent changes can each work, but when you put them together all hell breaks lose. The full build should start from scratch – no reuse of any object files or libraries (unless they are third party code that hasn’t changed). It also should have a full set of “smoke” or regression tests associated with it that test more than just the basic functionality of the code. Another key point that a lot of people miss is that if software is checked in right before the nightly build starts it should NOT be included in the build if the incremental build testing it has not been yet run. It should be included the next day.

I think that a lot of good quality improvements also can be driven through metrics – you just have to pick the right ones. For example, I’ve never seen a lot of success with Lines of Code written. Some software is inherently much more complex. Frequently the engineers writing the least number of lines of code are doing the hardest work – and the most sensitive from a reliability / failure perspective. They also can generate the most number of bugs per lines of code because of this sensitivity.

Overall bug trends as different levels of smoke, unit, and system test are run have been very helpful however. The number of bugs should ramp up steeply when heavy development and testing commences. Over time the number of new bugs (and total open) will level off, and then should drop just as steeply when the product is ready to ship. Using that data to determine the overall health of the product is key. However, once management starts to use that data to find the organization or individual who is to “blame” for the code instability strange things happen. The culture needs to be setup in a way to encourage people to track all bugs. If individuals worry about being blamed they will stop formally tracking their bugs and will even try to negotiate with test groups to make bugs disappear. It is an odd phenomenon, but it can be easily mitigated by how the organization reacts to finding bugs. Finding bugs is a *good* thing. The earlier you find them, and the fact that the customer didn’t is most important!

This clearly leads into test driven design methods. Whenever you plan to add new functionality, you add the automated tests first to go along with it. When the code is done, the tests better pass. Whenever a new bug is discovered you add a new test that clearly shows the problem and can later prove the fix for that bug actually worked. By doing this a product develops a full set of test cases as it grows. There is no need for a big test case development push at the end. Quality is tested in from the start.

Staying Competitive

In my spare time I play in a variety of competitive recreational volleyball leagues, both indoors and out. I’ve found that there’s nothing like a good team sport to bring out my competitive nature – I am one of those people that really wants to win. I don’t want to win at all costs, I am a proponent of fair play mind you but I do get pretty worked up about losing a silly game. I think that is because my team can be quite good – when we aren’t beating ourselves.

I find that a lot of the same things that can go wrong on the volleyball court can go wrong in business as well.

1. Teammates don’t have their head in the game. Getting distracted is one of the quickest ways to a loss. A good example of this is when there is squabbling amongst team members. Worrying about who is wrong and who is right leads to nobody worrying about what needs to really get done to win. Having teams with conflicting goals or direction at work can cause similar issues. Everyone is just looking for a scapegoat to pin the blame on rather than solutions to business problems.
2. Always worrying about the competition. A few weeks ago we played a team that wasn’t playing by what we thought were the rules (they apparently had changed for our league but no one was notified). Our team got so worked up about this that our play suffered. Instead of focusing on our game, we focused entirely on them and what we thought they were doing wrong. This can happen with your business competition too. If you are always thinking about what your competition is working on you aren’t allowing yourself the ability to be creative. You are going to end up in a role where you’re always playing catchup instead of in a role where you’re leading the industry with innovative ideas.
3. Not worrying about the competition. You can take #2 too far. For instance in volleyball the lineup against your opponent is critical. If they have a very strong server you do not want your weakest serve receiver dealing with that serve. You also have to make sure that you have a nice big block up against their biggest hitter. Failing to pay attention to the competition means that there are times when they surprise you and you end up scrambling to keep up.
4. Putting people in positions for which they are not suited. This one can be taken so many different ways. If you have a well-oiled machine of a team you don’t want to add someone that is way out of your league to the roster. This goes in both directions. Adding someone who isn’t competent can cause injury. On the volleyball court this type of injury comes from being knocked over or being hit in the face when someone is out of position. At work that person can inflict damage when they attempt to take on a task that is completely out of their reach. The higher up in the organization this happens, the worse the consequences. Imagine taking on capital financing that cripples the organization because of how it is structured. That is much worse than a junior programmer who doesn’t understand coding standards. At the other extreme you have someone who is leaps and bounds more proficient than the rest of the team. At first glance this seems like a win. The problem is that unless the rest of the team can step up to their level in a relatively short period of time that new person will be frustrated. That person will end up leaving the team and they might just end up at your competition with a lot of inside knowledge about your organization and its weaknesses.

Knowledge Management

This weekend I finally got around to reading a book that I have been meaning to spend some time with for a while now. It is “Knowledge Management” by Carl Frappaolo. knowledgemanagement
This book can pretty easily be digested in an afternoon and it presents the reader with an overview of knowledge management concepts and some interesting case studies. Additionally different types of technology that foster knowledge exchange are considered and the use of web based portals for accessing information is discussed.

The most fascinating aspect of this book to me was related to how culture (corporate as well as geographic) drives the attitudes of the individuals involved in sharing information and knowledge. Subtle management behavior and attitudes can foster knowledge transfer or it can create a competitive environment in which knowledge is hoarded.

If you are looking for an in-depth guide to applying knowledge management to your organization I would not recommend this book. However, if you are interested in becoming conversant in the topic and are looking for a starting point to learn more this is a good book.

Motivation During Times of Change

These days the economy is very uncertain. I think that everyone, no matter how fortunate their financial situation is worried about what can happen.  Companies are also facing these problems – just look at what were some of the most powerful companies in the country – in the world.  The big 3 automakers are looking for a bailout of proportions that we never would have imagined just a few years ago. These are the companies that make the news. But what about the little companies? What are they going through?

If you’re in a little company, now’s the time to really watch those expenses. It’s also time to figure out how to deliver the best product possible to keep the customers you have and gain any foothold available in the market.  Unless their pockets are much deeper than yours, your competitors are going through the same pain that you are right now.  Take advantage of it. In fact, if your competitors have much deeper pockets, they might not be focusing on being as lean and effective as they possibly can be. That will hurt them even more as things get better – as they invariably will.

As a manager, it is hard to motivate employees to be their best if they are fearful.  The worst part is that scared employees can create a self fulfilling prophecy of failure. Right now isn’t the time to lose focus. It’s the time to make sure that everyone knows that their contribution is CRITICAL to the success of the business.  Now is the time to put in extra effort. This doesn’t necessarily mean extra hours. It means extra creativity. It means extra focus on what is important and the ability to ruthlessly cull what is not.  It also means the ability to change quickly when a effort is not paying the dividends that were anticipated. The more agile your company is – the lower the likelihood of failure and the lower the probability of layoffs. Once people understand this it can be a terrific motivator. No one wants to lose their jobs.