21 methods to innovate

I couldn't help but to copy it from the source (http://feedproxy.google.com/~r/business-strategy-innovation/~3/dXCsA8Esff8/21-great-innovation-methods.html?utm_source=feedburner&utm_medium=email):

1. Copy someone else's idea. One of the best ways to innovate is to pinch an idea that works elsewhere and apply it in your business. Henry Ford saw the production line working in a meat packing plant and then applied to the automobile industry thereby dramatically reducing assembly times and costs.

2. Ask customers. If you simply ask your customers how you could improve your product or service they will give you plenty of ideas for incremental innovations. Typically they will ask for new features or that you make your product cheaper, faster, easier to use, available in different styles and colours etc. Listen to these requests carefully and choose the ones that will really pay back.

3. Observe customers. Do not just ask them, watch them. Try to see how customers use your products. Do they use them in new ways? This was what Levi Strauss saw when they found that customers ripped the jeans - so they brought a line of pre-ripped jeans. Heinz noticed that people stored their sauce jars upside down so they designed an upside down bottle.

4. Use difficulties and complaints. If customers have difficulties with any aspect of using your product or if they register complaints then you have a strong starting point for innovations. Make your product easier to use, eliminate the current inconveniences and introduce improvements that overcome the complaints.

5. Combine. Combine your product with something else to make something new. It works at all levels. Think of a suitcase with wheels, or a mobile phone with a camera or a flight with a massage.

6. Eliminate. What could you take out of your product or service to make it better? Dell eliminated the computer store, Amazon eliminated the bookstore, the Sony Walkman eliminated speakers and record functions.

7. Ask your staff. Challenge the people who work in the business to find new and better ways to do things and new and better ways to please customers. They are close to the action and can see opportunities for innovation. Often they just need encouragement to bring forward great ideas.

8. Plan. Include targets for new products and services in your business plan. Put it onto the balanced scorecard. Write innovation into everyone's objectives. Measure it and it will happen.

9. Run brainstorms. Have regular brainstorm meetings where you generate a large quantity of new product ideas. Use diverse groups from different areas of the business and include a provocative outsider e.g. a customer or supplier.

10. Examine patents. Check through patents that apply in your field. Are there some that you could license? Are some expiring so that you can now use that method? Is there a different way of achieving the essential idea in a patent?

11. Collaborate. Work with another company who can take you to places you can't go. Choose a partner with a similar philosophy but different skills. That is what Mercedes did with Swatch when they came up with the Smart car.

12. Minimize or maximize. Take something that is standard in the industry and minimise or maximise it. Ryanair minimized price and customer service. Starbucks maximised price and customer experience. It is better to be different than to be better.

13. Run a contest. Ask members of the public to suggest great new product ideas. Offer a prize. Give people a clear focussed goal and they will surprise you with novel ideas. Good for innovation and PR.

14. Ask - what if? Do some lateral thinking by asking what if…..? Challenge every boundary and assumption that applies in your field. You and your group will come up with amazing ideas once the normal constraints are lifted.

15. Watch the competition. Do not slavishly follow the competition but watch them intelligently. The small guys are often the most innovative so see if you can adapt or license one of their ideas - or even buy the company!

16. Outsource. Subcontract your new product development challenge to a design company, a University, a start-up or a crowdsourcing site like ive or NineSigma.

17. Use open innovation. Big consumer products companies like Procter and Gamble or Reckitt Benckiser encourage developers to bring novel products to them. They are flexible on IP protection and give a clear focus on what they are looking for. A large proportion of their new products now start life outside the company.

18. Adapt a product to a new use. Find an entirely different application for an existing product. De Beers produced industrial diamonds but found a new use for diamonds when they introduced the concept of engagement rings. It opened up a large new market for them.

19. Try Triz. Triz is a systematic method for solving problems. It can be applied in many fields but is particularly useful in engineering and product design. Triz gives you a toolbox of methods to solve contradictions e.g. how can we make this product run faster but with less power?

20. Go back in time. Look back at methods and services that were used in your sector years ago but have now fallen out of use. Can you bring one back in a new updated form? It has been said that Speed Dating is really a relaunch of a Victorian dance format where ladies had cards marked with appointments.

21. Use social networks. Follow trends and ask questions on groups like Twitter or Facebook. Ask what people want to see in future products or what the big new idea will be. Many early adopters are active on social network groups and will happily respond with suggestions.

Wiki for requirement management... Why not?!

Today I had a conversation with one of project managers. They need a tool that will help capturing existing system behavior in form of product requirements. I suggested using one of of-the-shelf solutions but he argued that they have good reason to stay within Wiki used for documentation management at the project. I doubted that Wiki is the right place to do this because of its limited functionality. So, it made me go to the Google and seek for the answer.

The result was better than I expected. I found out that many people did this and succeeded. All we need to do is following simple recommendations:

1. Do not let it become a mess

If several people are asked to write comments, change requirements suggesting variants it will soon become a mess. In order to avoid it, there should be strict rules and authorities to changes the requirements clearly defined within the team.

2. Keep it organized

Within time, Wiki description of requirements may deteriorate into amorphous, unstructured document. Especially when there are several contributors, each having own opinion on what it should look like. My recommendation is to keep the structure clear and understood by all contributors, so new articles appear in right place and connected to right pages.

3. Update it often

Do not wait until there are tons of changes to be done. Do it in small steps, immediately after a change comes up.

Wiki is a great tool for the collaboration. But as any tool it should be used wisely. As they say, a fool with a tool is still a fool. Don't be foolish. Find out about the issues before jumping into applying a tool to the process for which it is not intended to be used. Using Wiki for RM... Why not? But let's find out how for the beginning!

Happy requirement management!

Requirements: do it correct right from the start

Lately we had a quote from a client who was seeking for a help in writing software requirements. He was looking for someone to translate a unstructured input into a set of solid, high quality requirements. That was a wise step because requirements is where the quality of a product starts.

More and more people come up with ideas of a software product but the numbers of people who can transform an idea into a full spectrum of professional requirements remain too low. I will try to explain some of the ideas behind writing good requirements, so one could do this on a high level without a help.

Let's start with definition. Software requirements are a set of statements that define software behavior. Under behavior I mean the functionality available for the user or the characteristics of the software that directly affect its business success.

Aside from the qualities of requirements a big role is played by the process. The way you work with requirements defines their effectiveness in the development cycle. During the lifecycle requirements go through several stages:

- Creation or gathering
- Review
- Modification or update

As you see this is not enough to just create requirements. You have to have means to update it later, when changes come up. No matter how good at gathering requirements you are or how good you know what you want to have in the product, you will face change requests. They can come up out of review, development, testing, beta program and field usage. So, you must have a process how to deal about changes, so as to have the lowest possible cost of the update, making sure everyone interested is notified.

All above impose the following demands on the requirements:

- Correctness
- Completeness
- Consistency
- Non-ambiguity
- Testability
- Traceability
- Maintainability or changeability
- Sense of priority

Correctness means that your requirements shall speak the truth. This is not enough to simply state the truth once. You need to make sure that requirements are being updated timely.

Completeness implies the all the required information is provided. You need to remember who the customers of the document are. They span from developers through testers and deployment engineers toward technical writers and support engineers. In some cases, the customer also is a consumer. So, interests of all those people shall be taken into account.

Non-ambiguity means that there is only one understanding of what requirements say. Two different people reading requirements must have the same idea of what they speak of. There three possible failure scenario for this quality:

- Boundary shift ("up to 100" instead of "100 or less")
- Synonyms use (use the same term consistently throughout the document)
- Negative sentences (use positive sentences instead)


Testability is as simple as its name. You should be able to check if a requirement is met. And you should be able do this in a reasonable time and with reasonable resources. Testers are best people to judge upon it.

Traceability is a key to connecting different entities in your process into logical chains. Change in requirements may need according changes in design or test documents. To track those changes and update all connected entities correspondingly, we need to give a requirement an identifier. This is usually an unique number, that defines one and only one atomic statement.

Maintainability is how easily you can update it. The structure of the document defines how much efforts you may need to make a change. Duplicate information doubles the efforts, so use references instead.

Sense of priority gives the possibility to easily say which requirement is a must and which is nice to have. This is especially important when it comes to selecting tests for regression testing or shaking up the functional scope with hope to find 1-2 man months you are lacking in the development plan.

If you manage to write requirements that meet the above qualities then you are most likely to succeed. I would also recommend keeping it short. As one wise man said "conciseness is talent's sister".

Additionally I would recommend finding articles related to wording to be used in requirements definition. Following simple rules may help making requirement easier to read. All the more, the language is ambiguous per se. You may find in there which construction of language to avoid making it less ambiguous.

Good luck!

Change your environment!

I am back from a short vacation that I have spent with my family. It was good but too short :) Anyway I felt much better getting back to work after a week I spent outside the usual routine. The most important about my comeback is how I feel about things that seemed common and normal before I have taken a fresh look at them. Once I am back I felt myself full of ideas and desire to change things for better.

If we only could change the way things are being done on a daily basis it would open a whole new thinking perspective to us. Instead of banging at the wall with our foreheads we would oversight the problems from above and find a solution we never though as to be existing before.

Every time I come back from vacation things looks a bit differently. It helps me to see in them what I have overlooked before. Hopefully you have the same feeling coming back from a lengthy vacation. Let's trust our fresh look and change things for better!

Happy innovating! :)

Getting complacent is a killer

One of biggest problem of mature companies is becoming complacent. They used to make money, so they believe this is the time to gain. There is no more need to strive for the success. They are already there. Things do the way they used to be, etc...

Wrong! This is so wrong because those who do not think this way will be soon ahead of you. They will eat you for the breakfast if you do not compete, if you do not try becomming better, doing more and achieving things greatest than those you already have achieved.

So, wake up and find out what you can do today to be one step ahead of your competitors tomorrow! :^)

P.S. You may also research for "destructive management" to get more insights on how to manage a company that have signs of becoming complacent.

Who whants to test forever...

Today I heard from a coleague of mine that she is going to head off to development. She went to studying Flex technology and had showed not a bad result on the exam. So, most likely I will be in need to find a replacement shortly.

I never liked hiring testers who are about to become developers one day, who approach testing as starting point for the future career in development. On my personal experience, it didn't work too well. Despite I knew some brilliant minds who were equaly successful in testing and in development afetrwards, such things are rather exceptions. (Though there is a chance that a good tester make a good developer too. In contrary, I never saw a bad developer to become a good tester. I appologize if I hurt anyone by last statement though)

Testing and development are adjucent knowledge areas. But they are different. The skills needed for being a good tester are different from those, needed for a developer. If testers think in categories how to break things, developers mostly focus on getting them work. Satisfaction that we get in result come from very different sources. Few of us can feel well both ways. The majority are restricted to just one way of getting satisfied.

Aside from the different qualitties and knowledge needed for testing and development, a person who choses testing as the starting point most probably looses her time, getting wrong experience. Days in testing will be a plus in development, no doubt. It will surely help writing code with fewer defects. But it's the waste of time that could be spent on gaining purely development experience to fill in the resume. So, those who start from testing with aim to move to development do not waste your time! Just go right to development. No compromises!

Not to say what a waste of time of people who invested in teaching wannabe developer it is. It is a huge additional cost for the company. The company usually gets less than it pays for bringing such a developer up.

Anyway, now I am in the situation when I can only react. There is no possibility to change the circumstances because I cannot make that person think that her goal and inner desire are false. Partially because I know that she is sincere in her intentions.

Making the testing better

Despite unit testing has formal metrics that can prove at least minimal level of thoroughness; many organizations struggle to uncover measurement that can help telling how much of unit testing is enough. The minimal level of testing can be measured in terms of code coverage. Code coverage can be as weak as statement to as strong as du-paths. But this is not my goal to explain each of those. My goal is to help those who try finding an alternative measure of unit testing quality.

One of ideas is measuring it post-factum. Well it may be too late to know the truth. Nonetheless this knowledge can be used in the following project to reduce number of defects of a specific sort. I mean the feedback that you receive from testing.

Software is being developed in several stages. Even in Agile, there are stages; but they are shorter and tightly intertwined. Defects injected at a given stage can be found at that stage or at the following ones. Depending on how many defects injected at the stage escaped quality control, we can draw our conclusion about testing quality.

For example, we have created a unit and performed unit tests. In result of testing we have found and fixed 16 issues. But later when a unit comes to Integration and System testing, we discover additional 4 issues attributed to unit. This means that defect removal efficiency of unit testing for that module was:

DRE = (1-4/(16+4))*100%=80%

To enable this measurement you need to analyze issues found at later stages of development. If you have a defect tracking system (and I hope you do) then you can simply introduce the field that will denote to what of development stages a defect can be attributed. The biggest problem here is having defects found at unit testing stage filed somehow. Many developers see it as an additional unneeded paperwork. So, if you are going to implement this metric be prepared to the resistance. You may decrease the pain by claiming only brief information on unit testing defects to be filed (summary only). There are tools that can be integrated into development IDE to soothe this pain for developers.

Other testing stages' effectiveness can be measured the same way. All you need is to collect this information continuously. Two or three projects later you will have plenty of interesting information to think of:

- Why is this module's unit testing is lower in effectiveness than others?
- Why developer A usually produces higher effectiveness than others? Can the latter share the experience to the team?
- Who is responsible for most of the issues down the road? What can you do about it?

Hope this helps! :)

Management means no friendship?

Not so long ago I partook in a long discussion related to whether or not a manager can have friends among his subordinates. As I remember, the vast majority people in management role believe there is no problem having friendly relationships with your teammates.

But I remember another very successful manager (a top manager) who kept saying "you should not be a friend to your people", "you should not go to lunch with them". Since then I keep replaying this through my mind and all the time it responds with "It is wrong", so I cannot adopt this thinking.

To me, building unnatural barriers is counterproductive. Open communication is a key to effective professional relationships. People are smart enough to pick up the signs of too artificial behavior. They will mind a reason behind it and will start doing the same. So they will never be open with you.

The same top manager once told me "why you cannot speak to me frankly?" How could I if I did not trust him because of his ways of managing people?! That was kind of paradox that we could not solve. I guess he had same problems with others. I heard it many times that people preferred to talk to him what he wanted to hear, not what they thought. No need to say that he was not able to manage the team effectively. So, despite of his experience I would say that he was wrong. Friendly open relationships help managers doing the job. It does not free people up of the responsibility; it rather imposes the responsibility on them. Subordinates tend to feel badly when they did not do things right, when they couldn't keep the promises not only to a manager, but to a friend as well.

Of course, this way of management works not for all of people you will encounter in your managerial career. As I always liked to say "In management there are always several ways to do the same. The way that you like is not the only one. So, keep learning."

It may also depend on the culture. If you have anything to say on this matter I would gladly hear that.

What do you all think? Long to seeing your comments…

What makes a Good tester?

Everyone can easily say a good tester from a not as good one. A good tester finds more quality defects. But what makes one to be good tester? What is the difference that helps identifying important sound bugs faster?

First is technique. A good tester knows what the weak points about the application are. If it accepts a text for the input and produces a tagged text as the output, then most likely the issues will start popping up if you feed it a large volume of text. If it ate it successfully then change the text to something developer would not expect for the input. This is a sort of destructive thinking that helped my son breaking seemingly unbreakable toys when he was from 3 to 5. Thinking in categories "what else people usually omit?" helps finding more defects faster.

Second difference is the feeling of urgency. A good tester will explore entire functionality of the application rather than focusing on a small part of it. In result, the number of defects and the severity of defects is usually higher than quantity and quality of defects produced by testers bogged down into details of a specific dialogue. Likewise, a tester who focused on functionality will produce more quality issues than a person who is too deep into UI testing. Small issues reported early in the testing when application is full or crashes may make developers and project manager go mad. You are very likely to hear: "What are you thinking about?" So, better start from beginning and focus on how system works. Of course they may be exceptions. For example, it may be not reasonable to test a part of functionality and get back to it later. Anyway, if it does not cost too much I would rather recommend focusing on what matters now.

Third difference is level of expertise. A good tester can quickly imagine in which way a new functionality can affect the existing one. Knowledge about system functional and structural dependencies can help finding integration issues. Such issues usually have heavy consequence, so they are rated as critical.

Forth difference is seeing it all as a whole. A good tester always finds out how the functionality is supposed to be used and tries it on realistic tasks. There is no need to remind what use case or end-to-end testing is. This is all natural for a highly skilled testing professional to think of what real user is supposed to do with a system. It also helps finding usability issues. Recommendations on how to make system better are always welcome!

I wish all testers around would be good ones. Hopefully this article will help some of the readers to become one :)

Test design: do it right the first time!

If you are in software testing field you probably noted how difficult it is to grasp the idea behind the test cases when all you see is a collection of steps presented for review. This is too easy to get bogged down into step details. You may have even got this impression "Wait a minute! I wanted to review what is supposed to be tested instead of reading individual steps trying to compile them into logical test sequences!" If you did – then read on. Some advises may prove to be useful for you. If you never experienced such issue read on anyway. The fact you never noted the problem does not mean it cannot not hit you ;) Remember, this is not what you know will kill you.

The solution to the problem is of the same sort as we used to apply in other types of activities - early validation. So, you need the means to early identify problems with your design, until it gets "hardcoded" into written form, with steps and test data. The question remains – how to present testing ideas in a short and convenient for review form? There are a couple of ideas. Both proved to be quite successful in my experience.

The first idea is to generate a list of test conditions or test requirements before starting to generate test cases. The list can be presented in form of a tree:

- file types:
---- doc
---- txt
---- pdf
---- xml
- file content:
---- text
---- pictures
---- text + pictures
- file size:
---- large
---- empty

The time needed to generate such a list is negligible. You don't even need to bother about test data at this point. The whole idea you put behind the testing may be wrong, so time spent for creating complex test files will be a total waste.

Tree forms allows for easy review. It helps providing your thoughts in a structured way and keeps reader's attention at one context at a time, thus improving the quality of analysis. Seeing such a list one may easily find out that there are no tests for specific conditions (text in UT8 format for example). The only problem with this approach is that you do not tell how you are going to validate those conditions.

Another way is providing an overview along with your test design. It works as well to better review process, but it does not help against rework. If you have chosen wrong way in your design, you will need to re-develop your test cases.

Overview is written for the reviewer. It shall answer the following questions:

- What is supposed to be tested?
- How is it supposed to be tested?
- What conditions are to be tried out?
- How the results are going to verified?
- Whether or not automated testing will be used?
- Risks and limitations of selected testing strategy.

Having the answers on these questions will allow a reviewer to easily grasp the ideas behind the testing and to validate them.

Test design review is a hard task because there is a lot of a detail. The main goal of review is not to make sure details are correct. We are much more interested to see if testing design is adequate to get confidence that, once it pass, we have a quality product. There is no need to provide obscuring details to review. The early you present your work to review and the easiest it will be to understand it - the best quality and productivity you can achieve.

Resistance to process changes

They believe this is in the nature of people to resist changes, especially when everything is ok. Things go well, so why bothering with changes. The truth is that those who simply do things as usually never achieve great goals. If a company gets complacent it may even die, overruled by concurrent who took on the challenges.

Similar rule works for quality assurance, defect prevention, and process improvements in the organization. I always face resistance when I speak of the need in code design, review, and unit testing. Even most persuading words may break down upon the blind "prove me why I should be doing it". This is very discouraging when people nodding heads in agreement on the meeting, who look as if to buy the idea, allow it silently die a month after.

This is not reasonable to believe that another preaching session in a while will change things for better. Repetition is good but it's not enough to foster right attitude toward the case. People who are responsible for using the change in the process must believe the changes are needed. And what is more important they need to believe that they need it personally to do their job better. If you fail convincing them in it, there is little change your ideas will get due support. Another necessary thing is management contribution. Management shall keep insisting on following best practices. They need to patiently explain what the purpose of a process is and how it is going to help the team to reach the goal.

Only buy-in from performers and consistent message from the management will do the job. If one of these is absent the initiative will die a silent death.

Interviewing candidates

I have done it many times. A lot of lessons were learned. However, even now, from the heights of experience, I realize that I still can fail. The reason is that people are very creative if it comes to making impression. The more intelligent a person who sits against you in the interview, the more difficult it is to probe the true qualities of that person. Being smart is just one of qualities that you look in candidates. It defines aptitude to some degree. However, this is far not all that you may need to find out.

If a person is smart enough he or she may tell you rather what you want to hear, not what he or she is thinking. So, in result, you may get a wrong image of a candidate. Such a hire, if made, may prove to be wrong not only for you, but for a hired person as well. So, it makes sense to put it clear right before interview that this is not only the examination of person's qualities but also a test if a person fits the position. The later will be evident in a while. So, you both better not to waste time and to be honest. A candidate must be honest about achievements and experience as well as you must be honest in your responses (overtime work, salary increases, etc.). Lie leads to another lie. Don't start your relationships in the wrong way.
Now back to the interview… I used to think of candidates in terms of three A (Attitude, Aptitude, and Achievements). Fist two “A” are most important for newbie candidates. The last one is extremely important for a senior position.

Attitude is how a person sees his or her future in your company. This is a measure of desire to work in your team, the level of loyalty. And this is what candidates are dishonest about most of the time. So, do not believe just words. Look at the reaction of a person to specific questions. If there is lie you should guess it from the looks and gestures with easy.

Aptitude is how candidate's skills cover requirements of a position. Some things can be caught up at easy. Some can't. The difference is crucial. If there is anything in a candidate that makes you believe he or she will not be 100% efficient in a new role and if you are not sure you can fix that - never hire such a candidate.

Achievement is demonstration of the skills at the tasks similar to one you want a candidate to perform in the future. If the tasks are different and he or she will have to do incomparably different things then you better consider him or her to be a newbie.

Hiring newbie is more complicated because you simply do not know what to ask. Usually we ask people to describe what they did in the past and drive their talking with questions. A newbie do not have achievements to talk about, so you need to use standard cliché questions like "why you have chosen this domain?", "what have you read on this?", "what do you want to achieve in 5 years from now?", "what are you ambitions?" and so on. But those questions will reveal just a bit of a candidate. To learn more, I used to give them short tests, which allow me judge upon professional qualities. I use these tests for more than 10 years and have never regret about it.

What a test may be? Well, for a software tester this is a quick test to produce as many as possible tests for a simple function of a well known and broadly used software product. Calculator or Notepad will do just perfect. The answer not only indicates candidate’s natural ability to create test cases, it also provides you some feedback on how good a person is at using the software at all. You may guess it by the depth of the testing a candidate is generating. One may come up with tests for Undo operation, another may have it omitted.

Such tests can be developed for any position. For a developer it can be a test task to design a simple system using OOP, or to write a piece of code on a paper. For a technical writer it may be a quick description of some software function. System architect shall be able to come up with a solution to the architectural problem that you faced in the past. Or it may be just a sketchy design of a system described right at the meeting (chat machine of online magazine, for example).

Yes, such tests will require your time and time of a candidate. But you will hardly be able to gauge person’s abilities without it. Only practical task show how good candidate is at work that you want him or her to do in the future.

Of course, aside of above, there are still a lot of things to look at. How a person will be able to meet deadlines? Is the level of responsibility is high enough? Can this person learn new things quickly? Is there any problem with communication? And so on.

Sorry for this a bit clumsy but hopefully useful piece of information. I will get to it back when I have time to polish it.

Walking problem

What if one of your team members appears to be a problem? He or she may not fit into the team and having such a person among the others may prove to be too risky. People are getting infected with examples of bad behavior way too fast. (I wish they did as well mimicking something good, *sigh*)

The first advice is not to lay it off for too long. Yes. This is harsh business but it has to be done. Otherwise what kind of a manager you are? I usually start fro, talking to a person explaining him or her: what is wrong with the behavior and how it affects the team. Once a person is aware of the problem he or she can do something about it. In this respect, this is a service to a person that you do.

It may not be as easy though. Some people take critics personally. It may make your efforts all in vain. It helps to explain that the reason you are talking to your team mate now is not to "put in place" but to help, help to grow, help to get better.

Mostly, things are looking too good from the inside. We all fool ourselves that we work as well as it can only be. The reality is a little bit different. The extent in which it differs depends on our inner qualities. Some assess their achievements with due criticism. Some think that they do much better than others having no real reason to think so.

Your goal is to provide objective feedback on the achievements. Do not forget to mention good ones. It will make your team mate more open to discussion. And it's always better to start meeting from talking about positive achievements. Remember, you goal is a constructive discussion. Having someone in bad resistive mood will make things much more complicated.

Once you delivered your viewpoint explain the consequences. I usually make it clear if I am going to let a person go in case there is no progress on the improvement plan. This is tough but fair. Do not try to make corners flat. Just put it clear.

Then sit together and define strategy of how to make it all better for a person and for the team. Once you have a plan, define deadlines and metrics that will help making sure you have achieved the goals.

Following these simple recommendations may save you a lot of time and nerves.

"Easy money"

Who of us was not dreaming of easy way to earn money? Easy means that with little effort we get a big benefit. Well, I have one such idea for software developers.

It is laying right in front of your eyes. It is easy and does not require long learning curve. It is all automated. And all you need to do is to press a button. Then sit back and wait for a sophisticated report. And this is not a joke!

Code analysis tools -- cheap, fast and easy way to learn what's wrong with your code. You need not to run through all the code manually to find that it's not up to standard, unsupportable, dangerous, or not reliable. All you need is to feed it to a code analysis tool. Such tools made a big step forward since they were simply searching patterns using regular expressions. Now they can find unreleased objects and connections to help developers exclude defects related to resources usage, nasty ones, difficult to find and isolate. They can measure complexity of code to warn of the code that will be difficult to maintain. They can produce nice reports, easy to understand. Below is just an example of such a report:



So, do not waste your time and run code analyzer against your code now. Then see what it says to you. On the first usage, you may find it too paranoid about small problems. No problem. Tune it up to bring up only serious issues. It's all customizable. However, like in case with MSDEV warnings do not try to fool self. Those things are reported not just out of blue. There is a reason behind. If you don't understand the reason then it's better to leave the warning as is.

Enjoyable code analysis! =)

Innovation blog

Unlike many blogs on innovation, this one is practical and eye-opening. If you are interested in topic of innovation I strongly recommend visiting it: http://www.business-strategy-innovation.com/innovation-blog.html

Enjoy!

Newsgroups, Web 2.0, communities... What is next?

There are several newsgroups that I used to visit in the past. Now they turned out into nothing. This is very unfortunate. It was a great source of first-hand information on how different things they preach on in the magazines work in reality. Besides, it was the major source of the professional news to me. There I leaned that such things like Agile, exploratory testing, model-based testing do exist. Magazines are good. But not as good as the information refined with more meaning when passed through the experience of many people. There I was involved in long discussions and hot clashes of ideologies when eXtreme programming started to grow from the ashes of waterfall development model.

There are several things that mostly contributed to professional newsgroup collapse. First and the most important is a flow of under-qualified newbie. They have collectively and very efficiently drowned the discussion with a whole lot of meaningless posts, too much trivial for a person having decent experience in the field. People who monitored the group to find something encouragingly new found them browsing through numerous posts with questions Google can answer better in a second. All the more the questions were all the same the next day. It was so terrible that many of those whose posts I enjoyed abandoned participation and never came back.

All the professional groups I used to read now are sandboxes for advertising, spam, and silly questions. This is a mix that can hardly fit a demanding professional taste.

The next reason is the growth of popularity of various web 2.0 blogs and social networks. Many discussions simply moved to a new place d'arm. Recently I came across a starting whole war aka Agile vs. traditional development at LinkedIn. I simply passed by. Through the numerous attempts to stop the train I learned better not to do this. One who can efficiently use best lessons that Agile and non-Agile development have learned will succeed. Those who believe there is only one way (mine and wrong) are doomed to fail. Time will settle the dust down and we all will see that we are still where we were but with a little bit more experience and knowledge than before.

So, newsgroups are near dead. Web 2.0 is abounding. Special networks are going the way of newsgroups (they are already an advertising platform). So, what is next down the road? What else can we come up to effectively share knowledge and ideas? Google wave? -- Anyone?

Scripted testing or free flying?

The more I work in testing domain, the more I learn how difficult it is to answer this question. On one hand we need to be very diligent and specific about things we are testing. We have to be ready to answer what we tested and how. We have to collect information on what was tested and how in order to do retrospective review. On another hand, many test professionals believe that the best way to find a defect is get into something like a trance, a "free flying" through the functionality. Like a dog sniffing its pray, tester searches defects following gut instincts. This is way too difficult to organize in form of a checklist or guidelines. You can hardly explain what it takes to ride a bicycle or jump with a parachute to a person new to those activities. All you can achieve is "I have no idea what you are talking about" response. Same is for the testing.

So what is the best way for you, you may ask? The answer cannot be universal for everyone because each team is unique. The way we used to work, the qualities of team members and peculiarities of a task are very important. I personally believe that a mix of both approaches is what works better for most of the organizations. But what kind of a mix should it be? One may try to script everything, including tests executed once (executed and throw away), like in medical industry. Others may not bother having such tests written down on the paper, allowing some time for their testers to do non-scripted testing fee of any bureaucracy. What mix works best for you is a matter of numerous trial and errors. Try different approaches and see what effect it may have. If it's a waste of time don't do it.

Unlike test design based on product requirements "free flying" testing is in-context activity, so it takes less efforts to generate ideas. When you do not have application to click buttons and try different combinations it is difficult to come up with ideas. Modeling software behavior in mind is resource-consuming task. Your mind simply has not enough free processor time required for the creativity.

In general, scripted testing adds more organization and clarity in testing process. It helps in making the testing process visible and controllable, thus helping to meet deadlines. Having no test scripted, you can hardly say how long it will take to run all tests, because you can only guess how many of them you are going to execute.

So, the best way of dealing about it on the level of testing schedule is generating scripted tests against requirements (and don't bother too much about very specific ways of using software at this point) and allow a day or two (depending on how big the functionality is) for "free flying" testing. These two days are better to be scheduled at the end of the testing stage. Prior scripted testing will help removing blocking issues as well it will lend your testers time to get familiar with new functionality.

All is in your hands. Only you can say what is best for your specific situation. Good luck!

Why do many performance appraisal initiatives fail?

The key to company success is people. Performers is what build tomorrow of every organization. The way they spend their working time today directly affects the company's outcome tomorrow. Many companies do not just rely on people themselves to drive personal performance. Not everyone has that nagging second self inside which does not allow staying complacent.

Almost all companies want to drive personal performance. Many companies think that they do. And just a few actually do it. Despite the idea is quite simple, implementation is what makes the difference.

There are almost infinite numbers of ways, in which a good endeavor can fail. Personal performance management is not an exception. Below are recommendations, failure scenarios and things to avoid while establishing a reliable performance management program. I have derived it from my own experience. It comes from the real world cases.

Process tips:
- Do it regularly, but at least once a year.
- Do it consistent throughout the organization.
- Gather information for the appraisal from more than one source (the more, the
better).
- Provide improvement plan within the appraisal.
- Track improvement plan execution.
- Meet in person to discuss the appraisal.

Failure scenarios:
- Lack of initiative on management side. Managers clearly do not understand why they need it. As the main driving force is down, the whole process collapses. In order to avoid, one needs to sell off the idea to managers, so they agree spending time for working on appraisals. Create a plan and demand following it strictly.
- Lack of credibility to what is stated in the appraisal on the side of the employee. In order to eliminate this factor, let employee know how many people participated in providing information for the appraisal.
- Attempting to create a Magic formula. Quantitative metrics (how many lines of code, defects, tests, etc.) are good source of information on performance. But those metrics need additional analysis. How complex a problem solved was? How big was the responsibility and time pressure? What was the quality? - Do not try adding more parameters to cover all those deviations! You’re either find yourself in the middle of near infinite number of scenarios or you will fool yourself with some compromise variant (one of many). Better stick to qualitative parameters (excellent, good, mediocre, bad) to assess the appraised features.

Things to avoid:
- Subjectivity is the killer. Gather information from as many sources as possible.
- Disagreement can severely undermine the efficiency. Make sure all disagreements between you and employee are settled.
- Taking it too lightly can let any good initiative die silently. Keep re-stating how important it is for the company and the goal the process is pursuing.

Following the tips above, having in mind failure scenarios, and avoiding traps will help you define the process that actually works. Good luck!

Disruptive business model or anecdotal boss?

Today I have read a good article on disruptive business model (http://feeds2.feedburner.com/business-strategy-innovation) that reads we should never allow neither ourselves nor our team to get complacent, to simply enjoy what we have instead of looking for way of how make it better. I absolutely agree with the author that putting right amount of pressure on the team creates additional innovation force within the organization. We need some strain not to feel comfortable. Overcoming obstacles of "never did that before" and "it isn’t going to work" is what fuels innovation. There is a big difference in results when people start looking for how to get there instead of whining about something being not possible.

However, there is clearly a room for a top management to misinterpret the idea. One may believe that the first part is not as important as the second. A CEO may think that the people who work for her must find the way of getting where she wants them to be and in time she wants. This is the beginning of the end. If you want your people to be inventive start from yourself. Show them the way. You are here not by chance. You took the position because you were superior and exemplary to colleagues. So, where is it now? Is it gone when you stepped up on a highest position? No, I don't believe that.

Instead of blindly pressing on your subordinates and complaining they did not do this and that try to organize a brainstorm sessions with them. Hear what they say! Do not try to play dirty games setting them off for failures just to replace them afterwards with a sigh "they are not up to our standards". When a person at so high a position starts acting this way, this is not going to stay not noted. People around you start seeing you as a person who can't hear what they say, so there is no difference what to say at all. After several unsuccessful tries to be heard they forget the idea and things start drifting to the pitiful end results.

A fool with a tool is still a fool. Having such a powerful instrument as disruptive business model implies responsibility for possible misuse. Do not fly too high. This is not king's court games that we are playing. Bring your ideas to the table, so everyone can see you are still a part of the team, not an icon or an idol.

Looking back makes a step forward

I'm a big fun of learning on own mistakes. I hate making the same mistake again. It makes me feel really bad. Repeating the mistake again can be a sign of lack of care for the end result. If one does care then he or she would mind to avoid running into the same problem twice. Sometimes we repeat our errors because of short memory. In this case I would suggest keep records of what went wrong and to buid a reliable guard against mistakes by changing the way we do things daily.

Same is for the process. Post mortem or retrospective reviews help remembering what went wrong on a project and give you insights what steps to take in order to avoid running into the same problem again in future. Just a look back may make a big difference in the way we do things. This is why I like it so much. With almost no efforts it provides plenty of ideas on possible changes. Here is the list of questions that I would ask to everyone who has been involved into the project:

1. What was good about the project?
2. What could be done better and how?
3. What was bad and how to avoid it in the future?

It also helps if you direct people thinking into concrete direction with questionnaire designed to elicit more details on the problems:

1. Did all the stakeholders have the same meaning of project goal?
2. Was documentation sufficient and clear?
3. Was system design profound enough? Did it make coding easier?
4. Did architecture help building a quality system?
5. Was change controlling mechanism effective?
6. Was the testing adequate?
7. Are you happy with defect tracking process?
8. Is the resulting product easy to support?
9. Was the planning accurate enough?

The list of possible questions can go on and on. This is up to you to decide if to mess with it. Every project is unique in the way things went wrong. Every team is unique in the way it fails. So, there is no universal list of questions. If one would try building it, it would be too general or too long. I recommend such list only for the beginning or to address a specific problem of retrospective review process (for example, people may tend skipping one of the processes from consideration).

The best way to generate list of improvements is to look back on the whole process from the very beginning step by step. Play it back from the moment you first heard about new product till the moment a release was sent out to end users.

It was always interesting to me how a retrospective look changes how thing look like. Some issues are being noted only if the whole process is played back. Thos thing may not even look like problems when you face them in day-to-day work. Sometimes we need the context that is yet to come to validate the decision we are making today.

Another very interesting effect is having issues indentified when you look at the whole process on a high level of abstraction. Thing that eat up several minutes a day may start looking not as negligible when assessed in perspective of several months of execution by ten people.

Do not let yourself fall a prey of excessive self-confidence. Your team may learn from mistakes as well as it may not. Make this process defined and visible. Share the ideas, implement the changes to the process and forget about the issues forever. This is much more reliable and natural than relying on everyone's personal memory.

Black sheep

Today things reminded me of a problem most of team happen to face from time to time. One team member who clearly misbehaves and takes goals and values of the team for nothing does not only contribute little but can even prevent others to contribute.

The problem is as serious that it shall be addressed immediately. The first thing to be done is trying to show that person how his actions impede team's success, how it looks like from the outside. If it does not help then the only option is to replace that person with someone understanding that team goals must be placed over the personal. In many cases personal goals are in conflict with those of the team.

My personal goal can be to browse Internet in the morning, whereas team goals tell me that I need to get the work done first. My personal goal would be making myself non-replaceable by concealing crucial information and experience. Me as a team member would do whatever possible to reduce risk for the team of being too dependent on me. I may get sick and there will be none capable of continuing what I was doing. The list of examples of such conflicts can go on and on. Do not anyone to show others the examples of wrongdoing. This is very contagious.

From my experience, it takes a lot of efforts of the wrongdoers to realize what it takes to be a part of the team, to serve a goal higher than what is on the mind just now. But until people get there one can hardly do anything about it. You better find another team member who will produce rather than complain.

Good and bad about process improvements

Improvement is always something positive as it makes the processes better. However, process is a fine mechanism that needs delicate treatment. Many times the ideas that were deemed a quantum leap ended up with just slight changes in the quality of output. The reason why the reality does not fulfill our expectations is in relative complexity of the processes and the number of factors that influence the outcome.

There is also a problem with preciseness, with which one determines the root cause of a problem to be eliminated. For example, we have a big number of small UI defects and decide that additional check by developers will dramatically decrease the number of such issues escaping coding phase. However, we may be wrong about the actual root cause. It may be not due to erroneous development but rather due to obscure requirements. So, the actions we defined may not bring the desired results.

Most of ideas on process improvement come from the performers. In order to get the feedback you need to learn how to listen what people say. Encourage constructive criticism on the processes. Never give up the feeling of resistance to the critics even though what is being criticized is your precious creation.

Metrics is another big-big source of clues on improvements. They say measuring without a clear idea of the purpose is not a good idea. I would argue this statement. I have a very positive experience of collecting everything possible I could collect about the project with successful usage of that information in decision making and defining improvement program. So, if it takes just a bit of time do not hesitate to jog numbers down. Who knows what application you may find for it tomorrow? Everybody knows that having historical data is a key to every performance and quality tracking program. The sooner you start collecting your data, the better. But please do not pay too much of your time to it. Else you will not be able to do your job!

Improvements should be carefully estimated and prioritized. All the more, improvements shall be carefully planned. And here you have the most difficult problem - resources. This is normal that all company's resources are busy on tasks directly contributing to revenue. And it may be difficult to detract your colleagues for working on process improvements. In my experience, most of good improvements get killed by this limitation. Here you have two options: procure resources by communicating goals and ROI to top-management; find enthusiasts who will do this in their spare time. The latter is not likely to happen so do not rely on it too much. I knew a manager who always appealed to enthusiasm, whereas everyone was reading "overtime" between his words. I always wondered why did hi not call things their real names? %)

Once you have a plan mind to define measures that will tell you whether you actually changed anything, and whether the changes were for good. Metrics are vital in every process improvement program. Else you will definitely persuade yourself that what you did was good, no matter of the real end result :)

Good luck in your improvements!

Listen With Your Eyes

I came accross an interesting study that indicates that verbal comminucation is far not the most effective way of coneying information. It turned out that our emotions and gestures can be more informative than words.

Here is the excerpt from the source:

"One study at UCLA indicated that up to 93 percent of communication effectiveness is determined by nonverbal cues. Another study indicated that the impact of a performance was determined 7 percent by the words used, 38 percent by voice quality, and 55 percent by the nonverbal communication."

Read more at: http://humanresources.about.com/od/interpersonalcommunicatio1/a/nonverbal_com.htm.

Automated tests: the sooner the better!

This is the most impressive experience I gained in my entire professional career. Read on and you will probably find it worth of trying.

Several years ago we faced the need to dramatically increase test automation coverage. Let the reasons be aside for now and let's focus on the problem per se. We had complex UI-driven software, full of custom controls and volatile UI elements changed from release to release. Our experience in test automation was refrained to the collection of several hundred tests that we occasionally used for smoke and regression testing. In order to get where we needed to be we had to automate ten thousand tests in a very short period of time, 1-2 years.

At the first glance the problem had no solution. It was really hard to be in that situation, when you see no way out. But we started the project having no idea if it's going to be successful. We started from optimizing of what we already can do, divided team in two sub-teams (one team focused on test design and manual execution, another took responsibility for test automation). We also introduced all the best practices that helped us to keep test production and maintenance cost low.

But this was not enough. Automation team was always behind testing process because they needed time to implement and debug test code on a working system. With insignificant exceptions, so, we could not use automated tests for functional test execution during the production cycle. We could only use it for regression testing of future versions. Tests still needed to be executed manually at least once. It had severe impact on testing schedule and drug us back because manual team was always on a critical path.

Then we’ve got an idea. It was as easy as it could only be. As far as implementation phase is what makes automation team fall behind we have to shorten it somehow. Adding resources is not an option. We already had several people working on this project and adding more people could severely increase overhead cost of communication. We went anther way.

Instead of adding resources we decided to move a part of test automation preparation task back in time, to do them in advance. We decided to do design of automated tests long before a working version is made available. Design means that we created fish bones of tests. Those tests used virtual functions that, when implemented, allow manipulating application features. Functions remained not implemented until we have a working version of a product in our hands. So, the tests could not be debugged until that time. But the most of design work is already done. And our experience indicated that this part is very significant.

When a new version of application comes to testing, automation engineers started implementation phase. They simply added code to the helper functions to make the test work. After that they run and debugged tests.

I will demonstrate how it worked in example:

1. We need to test a web search system that allows users to run the search, browse results and bookmark interesting findings.

2. Automation engineers select tests for automation. For example they have selected the following tests:

a. Different types of queries ("", "my search", "very-very-very long string").
b. Browse results (pages 1 through 10).

3. Automation team has steps of tests and test data defined in the test description created by manual team. So, thy create test architecture design like this:

test 1 - Different types of queries

test01_Search (String query, Integer expected) {
login();
doSearch(query);
assertEqual(getResults().totalCount, expected);
}

Used functions login(), doSearch(), and getResults() are not implemented so far! We have only figured out which functions we will need to enable our tests work.

Note: In order to do it safely it is recommended to insert a string of code that will fail your tests until function is not implemented, like this:

function doSearch(String query) {
fail('Not implemented');
}

Test that go through pages of results could be looking like follows:

test02_Paging (String query, Integer expected) {
String[] pageTokens = {"page1", ..."page 10"};
login();
doSearch(query);
for (int i=1; i<=10; i++) {
goToPage(i);
assertEqual(getPageToken(), pageTokens[i]);
}
}

Same way we can Design all tests that we selected for automation in advance. Thus we are saving this time from implementation and shorten the duration of automation. As practice had shown we can save up to 50% of time allocated for test automation. Roughly assessing, design phase is accounted for a half time allocated for the automation. So we shorten the second phase in a half, allowing automated tests to be ready sooner in the testing cycle.

Using this technology we have achieved the ratio of tests executed manually and automatically 1:1. This means that only a half of tests were executed manually each new release. Another half of tests were executed as automated right away. This had greatly increased automation ROI because we had no need to execute them manually at all and saved up to 40% of manual testing resources each release. Additionally, automated tests could be used for in-project regression testing much earlier. It also helped to get much of benefit from the idea.

In general, this approach had completely changed the role automated testing played in our project, making it at least as important and effective as manual testing.

Hope this helps making your test automation effort more fun! :) Feel free to comment should you have questions on details of implementation or should you have risks that may prevent you from having it work for you.

Team or group?

I heard the opinion that most of work units that we used to call teams are actually groups. One of important team's features is having universal performers, so as if one person is out the work can still be done by another. This is not a case for the groups, when people tend to specialize in some area. Replacing such key people with other is always a problem because the knowledge and skills they accumulated are unique and it takes time to train someone else.

Another difference between teams and group is structure. Teams do not have defined leaders; there are no superior and inferior members.

Modern software developer processes tend to favor teams over groups. Agile encourages cross-training, sharing goals and discourages traditional management practices because they divide people into “us” and “them”.

So, what is better? I can't say for sure because the answer will depend on what you are trying to achieve, who work for you and the way people are motivated. If you can share the success of a project evenly then it would be great to have a team. If there are different levels of responsibility defined and if shares will depend on those levels then you need to stick to group organization.

I am sure that if done rightly teams and groups can be similarly successful.

Personal performance monitoring and management

We all see the world with obscure eyes. We believe that people around us think and act same way as we do. The truth is that we are all different. What we see to be a problem can be accepted by another person as a normal behavior. The art of team performance management is in making all facts of misbehavior noted and corrected.

The first step on this path is giving another perspective to a person. For the sake of experiment ask your manager to jog down 3 strengths and 3 weaknesses in your professional behavior. Most probably you'll be surprised with results. The difference comes from different mindset, different criteria of assessment and different priorities used by you and your manager. Having a look from the outside is always helpful in determining where to direct your self-improvement.

Performance appraisals are written to provide independent, unbiased, and detailed enough perspective of someone's achievements, strengths, and weaknesses. It helps looking at all these things through the prism of another system of values. The best result is achieved is the system of values not that of a manager but that of a team. This is not as easy because performance appraisals are written by managers. But this is possible.

In order to define proper system of values, or a measure, you need to define what your team needs more in order to reach its goals. Find out qualities, which, if excelled by individuals, will get you closed to the goal. Here is my list, for example:

- Qualification
- Quality of work
- Quantity of work
- Responsibility
- Timeliness (ability to meet deadlines)
- Communication
- Initiative
- Creativity
- Flexibility
- Learning from mistakes

You may use this or you define your own list of qualities. It works best if defining such a list is a collective effort.

After we defined the list of qualities you may start giving marks to team members. Most of errors in implementation are made at this stage. Managers who perform assessment may provide subjective mark that does not only serve the purpose badly, it also may be counter-productive. There is no mistake worse in the management than under-valuing someone. People feel such things very keenly and take it very closely.

So, in order to use a team-oriented system of values we need to collect information from the team. Ask peers to fill in assessment form for a person. In parallel, write your own assessment and them compare one against another. And not only that... The difference you find should be explained!

Once you have finished adjustment, you are ready to write an unbiased team oriented assessment. While writing it keep in mind that you may face resistance to accept some things in it o the side of a person, who is the subject to the appraisal. Make sure it has examples of good and bad behavior highlighted in it. If you have difficulties in remembering such examples, ask your peer reviewers to provide them.

Reading appraisal to a person is another possibility to screw it up. Do not make it painful. Explain that the reason of it is to help your team mate to grow, to improve. Make him or her feeling comfortable with a joke or two. But do not go too far. Do not make look like a farce. This is a serious business, a team's priority one.

While describing and reading assessment start from the positive achievements like this: "You did very well at writing ABC driver. It was a complex task, new to you. Anyway you performed it on a very high professional level. However, the depth of testing was not enough. The defects discovered after you by testers where mostly of unit type. A least 10 of 15 defects could have been removed if you performed unit testing well enough".

And the last but not least, the marks! What is it going to be? I prefer qualitative marks:

- Superior
- Sufficient
- Insufficient

Superior means that a person can be an example for others on the team. Sufficient and Insufficient speak for themselves.

Such marks can be set against qualities for your team mates and can be used in team ranking or even for comparing your team's people against other teams in the company. In result of such comparison one may come up with enterprise level ranking for all employees - a dream of every CEO :)

Hope this helps and have a nice assessment!

Ho to obtain good estimates?

Today, we will speak about eliciting estimates from people. It would make the task easier if your peers who oppose you in this matter would read "how to make good estimates?" first. Even if they didn't this is in your hands to lead them the right path.

First of all make sure the task is understood by the performer. Ask him or her to paraphrase the assignment to you, so you can correct it until it's too late. This is also important to help the performer understand what other task performed in the past could be used for comparison or verification of the estimate. Sit down together and find what you did before that can be measured up against a new task (similar project, task). However, be careful to use examples more than 3 times bigger or smaller in size.

If you don't have examples and the task is completely new to a performer then define the plan how to analyze the problem (investigation, prototyping, consulting gurus, etc.). One of most important parts of this stage is having a concrete goal, a milestone when the investigation will complete, or at least a date of its completion will be known.

Once you have got first estimate do not accept it as is. Question it. People tend to take estimates too optimistic, so they have troubled in meeting them afterwards. In order not to fall prey of wishful thinking, start asking "what if?" question. What is that part will not be delivered to you for testing at the date you assumed? What is if it will take longer to test your code? I have seen that testing of such modules takes up to 30% of development time. What if you have no product requirements finished at the desired date? What else you can do to mitigate that risk? Asking such questions will help you analyze different scenarios of "how it may go wrong". Such scenarios are usually neglected by people who used to think overly optimistically.

This is also helpful to build your own estimates or to ask another expert to provide a variant of the estimation. Comparing alternatives is a key to finding out what is missed from consideration. Creating estimates using different parameters is another way of drawing alternatives for the analysis (calculate time needed to test out of development hours vs. the same parameter calculated from the number of requirement). Never use average, or some percent of several estimates. This is completely wrong because our goal is to find why the estimates are different, so we can correct them with new information that has been missed from consideration during the initial estimation.

This is it! It's pretty easy and straightforward process :)

As for the methods of estimation I recommend you reading "How much does a project cost?" by Steve McConnel.

How to make good estimates?

All of us faced the problem of giving estimates. The problem here is that sooner or later we have to meet the milestones planned out of our estimates. When we can't - we get our due portion of frustration from managers.

Estimation is a projection. In order to do it precisely you need to know of the task as much as possible in advance. If a task is new to you then you hardly be able to predict all the details with due preciseness. Best estimates are made for the task that we know well. The more we know of the task, the more precise our estimate can be.

We can compare the task against other known task we performed in the past or we can just use our experience with similar tasks. If we never did anything alike before then it makes sense to do research or a sample that will provide you with clues on how long it make take. For example, you need to translate all the code from Visual Basic into .NET but you didn't do that before. Before giving estimates, you can select some piece of code for a sample, port it to .NET and extrapolate the result to the whole bunch of code.

Estimate is the measure to something that did not happen yet. When we talk about future we always consider different variants how things may go. Many defects created by newbie, new development environment or even power supply may bring us some surprises. As far as we assume and measure future, every estimate implies probability. Point estimate (like 8 or 10 days) has almost 100% probability to fail (because the actual work can take 7.5 days or 11 days). So, this is not very unwise to give point estimates. Make it a range and share your vision on probability. Whatever you chose for a range of values it should be big enough to make you confident you can make it.

For example, if I would be asked to provide estimate on the weight of a space ship (that I have no idea about) I would provide a very rough estimate. Rough means that the range would be really big (50 to 200 tons).

Rough estimates are not what will make your manager happy. Actually he or she will be a bit confused and perplexed by it. They can't use it for planning. To resolve his or her confusion you need to express what you are going to do about it. Tell your manager what other information or what prototyping or online investigation you have to do to learn more about the problem.

As I have written above, the more we learn of the task the more precisely we can project on its pace and timing. Do not hesitate to ask for help. Managers can also be useful ;) They can help you finding the required hardware or procure tools. They can even suggest who to ask for the consultation on a specific problem. Inform you manager what else you need to learn about the task before you can make a more precise estimate. Also, mention when you can revise your estimate so a manager can adjust his or her plans accordingly.

A good estimate may undergo several revisions before it becomes reliable. A reliable estimate is what you believe you can make almost for sure. "Almost" is for the contingencies that could hardly be predicted in advance (power down, system crash, network problems, illness of key people, etc.).

In order to improve, keep tracking the preciseness of estimates on different stages (project initiation, design, implementation, testing, and maintenance). Analyze deviations to find out what to focus on in the future. Achieving preciseness of 10% is considered really good.

Following these recommedation you will find out pretty soon that making estimates is not a pain but fun. Good luck!

P.S. Next post will be on how to elicit good estimates. Stay tuned!

Microsoft vs. Google

Growing net book market is what both MS and Google are targeting with their new operating systems. Both companies believe in their projections that this opportunity will grow significantly in the nearest time. Even now few can imagine what they can do with a computer without Internet.

MS is ahead but Google seems to be in better shape for a long race. Google controls a big part of Internet and it makes it easy to enter the market. So, MS brand and popularity will not be such a big deal. Google will also open codes of their system. They believe it will help closing the gap in number of software solutions available for their system pretty fast.

Besides Microsoft has an advantage on this market Google can singnificantly undermine their position on the market of OS for mobile Internet devices.

Anyways, it's going to be a triller. End users will inevitably win from this competition.

How much does quality cost?

This is natural to think that in order to get the perfection one needs to pay for it. This is really hard to argue. However, what comes to quality, things may look not like they seem at the first glance. Quality may cost you additional time spent on operation that you would not do still producing a good product. But we all are humans and are not perfect in sense of quality of our work. In other words, we do make mistakes. So, we need all these additional measurements within the production cycle that allow us to see if the product complies to standards and requirements.

But when we talk about time and efforts spent on following procedures which only purpose is not letting us making the errors we should not forget about savings that we get using them. We have introduced all those practices not just in case but in response to problems we had in the past, in response to defects introduced or missed in the previous production cycles. Having deprived of them is going to save our time and resources!

The formula of quality cost includes not only explicit expenses on following quality processes but also implicit savings we get from following them. If you do not have savings then why bothering to do unnecessary actions? Even if process changes are introduced "just in case", we still do it to decrease the risk of having some problems in the future (lost user data -> frustrated clients -> bad reputation -> drop in sales).

In any case, if we make changes to the process we believe that we are going to have some saving, be it lower number of defects found at system testing, or fewer calls to customer support. So, we can infer that quality does not cost us money. Instead, it saves us money!

If you are still not convinced that introducing quality practices does not cost you a coin, just look at two automobile vendors: Alfa Romeo and Toyota. Both cars can be in same prices niche, both provide similar functionality and cost almost the same, but the difference in quality is huge. It's remarkable that Toyota does not spend more money for producing its cars than Alfa Romeo because they have a good quality system installed. So, they spend more at the early stages of development to save time at the later stages.

In order to create such a system in your company just look at the history of previous projects. Analyze defects that escaped development and testing phases. Try to estimate cost of one fix at different phases, and introduce practices that will eliminate most popular mistakes. You can easily calculate savings you will get from introducing those practices. Then simply compare it to the additional cost related to following those practices. I am sure the benefit will totally overweight the overhead expenses. If it doesn't just write me back. I am interested in that sort of anomalies ;)

I can generate all tests! Wow!

Today I partook in Beta program for a test generation tool. This tool accepts the list of parameters with possible values for the input and generates combinations, which represented virtually complete coverage (all values of all parameters represented at least once).

Despite the idea is good, the actual use of such tool is in doubt. Of dozens systems that we tested I could name one or two where we could apply this idea. The idea of cutting testing cost by combining test input is not new. I have got acquainted with it while reading Marick's "The craft of software testing" in the end of 20th century. Author tried to minimize test count by carefully combining input values, taking into account dependencies between them. It was beautiful but it proved to be useless in the real practice. The time spent on optimizing tests can be easily spent running more tests (including those, removed with optimization).

Another problem with the idea is that combinations cannot be seen from mathematical point of view only. There are other factors that can affect selection of combinations to try. We may know that testing under a specific browser is more important because it is very likely that application can fail in it. Whereas testing under another browser can be minimal because we know that all development is performed using it. So, the context does matter and test generation tools shall take it into account or they will stay as useless.

Who to blame for bad quality?

"What a silly question?" a CEO would say and call for a quality manager: -"Bring me that looser. I told him more than once that this is not acceptable - to produce the software with critical defects. It hurts our business and stay in way of expanding it beyond the limits of Solar System."

Many times I saw how managers point their fingers to a person who bears word "quality" on the working title. But I saw few of the latter who could really do something. What is it then? A person who to blame no matter if he or she could do anything? A sacrifice goat whose fate is all pre-defined?

And what is more important - what could we, quality professionals, do about it?

Once I've been at a meeting with a big boss who very convincingly explained to us that of all the corners of a famous triangle (quality-feature-time), quality is the most important. "We never compromise quality!" he told. I was in love with that idea and was full of esteem to that person by then. But... within several releases I realized that those were just words. He did not think so. Every new release features prevailed until application started to look like a monster, a biting monster, because users were not happy when it crashed in their hands way too often.

So, who that boss should blame for the quality?

Before claiming the answer to the question "who is guilty" let's focus on solving the problems that we have in development and management that led to defects be injected into the code and not found during testing. After that, have people directly responsible for letting those issues go analyze the way they work and provide you concrete improvement actions which will help avoiding similar omissions in the future. But, doing so, keep it impersonal. Let them know that it's ok to make mistakes until they learn from them.

As for the question, if you want to blame someone start from you. Just ask yourself what would you do about the problem? How could you affect the process, so the issue is not injected or removed within the production cycle? If you are not perfect, you will always find something to improve, to grow. Answers to above questions will provide you with some insights.

Another very important thing is not to start finger pointing until you know the root cause of a problem. Make sure you have argument to prove someone guilty. Otherwise you risk to severely under-mine the moral of a person in whose performance and contribution you are interested. There is nothing worse than thinking whatever you do - you'll get blamed. This is a killer to motivation.

So, the short answer to the question is to start from you. The more in-depth answer would be: find out the actual reason, have people involved analyze the problem and come up with action plans, make corrections to the process.

Motivation - are we all the same?

Motivation is one of most appealing management tools. Motivated employees can produce more of the product and with better quality. Many companies work on their employees’ motivation to get the best outcome. Introducing bonuses, providing cars, better working environment, and social benefits - all aimed at keeping workers, clerks, and managers motivated.

But what is the motivation itself? Is it the same for a person, who likes washing windows so much that he can't wait until tomorrow to go to work, and a person who wants to organize things so, as to sit back and see things moving round in a well-organized way? Are these two kinds of people thinking the same categories? No. They even have opposite motivational goals.

Today I have read an interesting work on motivation. Author was speaking of three kinds of motivation:

- Rational (I love my job and I have a natural desire to do more, to do better)
- Irrational (I don't like working, I better make things turn around themselves)
- Egocentric (I can stand anything if I get promoted)

People of rational type of motivation enjoy the work itself. They have a natural desire to work more, to work better than yesterday. They find motivation in what they do.

Second type is completely different. They do not like working. They are motivated by... laziness. No. This is not a joke. And such people are not losers. Most of innovations come from this type of motivation. The many of this sort have their own business, which they started having perspective goal to sit back and watch things move on their own.

Third type finds motivation in esteem of peers and management. They are clearly of extravert type. They do care what other say about them and how they see them from the outside. You can keep the salary of such person relatively low. Having a good career perspective, such a person will work the best.

Each of three groups of motivation requires different actions to keep it warm. Instead of looking inwards companies prefer to stick to one type of motivation that, in their opinion, can target all the types of individuals. So, we should not be surprised with the results.

Identifying the right motivation for your employees is vital for your business. It's hardly possible to keep "sheep safe and wolves full". There are different types of personalities working for you. Learn them and find the best way to manage their intentions and to use it for the success of your business.

Thanks to author of that original article for insiping me on writing this.

The outsoucing thorns

When I first came to the outsourcing company I was perplexed and confused at the same time. The entire set of values I brought with me from a company that worked on domestic product was hardly applicable and required significant adjustment.

First thing that made me nervous was the absence of a defined development model. Each project was a small company per se with its own game rules. The set of rules depends on the qualities and experience of a leader (PM) and customer will. This is not arbitrary that I placed leader in the first place. PM is more influential figure in the project than it may seem to be. Few customers come to the outsourcing company having enough experience in software development, so they know how to organize the process. Most of clients are new to the domain and have vague idea about peculiarities and risks related to software development. A strong project leader can correct customer's vision of the problem to a decent extent.

Another difficulty was the dictate of the rules by customers. There were problems selling off testing services, especially in the difficult recession times. Testing is being seen as an additional cost. Testing does not create the direct value so it was perceived as a good candidate for cost cutting. Some customers even insisted that they will do testing on their own. I am not sure they realized what it would cost them. I am sure they would find a better use to their precious time. This looks even stranger if we think of a pitiful experience in testing they usually have.

The third problem is also related to the company being split into small reins with their own small kings. Introducing changes is a much more painful process. If it can be done only with enthusiasm in the "domestic" company, this is absolutely impossible in the outsourcing without a constant support from the top management. You simply find yourself bogged down in communication maze with all the parties interested, each of whom have their own vision of the problem, and each of whom used to adapt different kind of processes.

This is, in general, the core difference between testing and QAing in "domestic" and outsourcing companies. Having experience in both worlds I would suggest you to select the former if you want to learn building quality processes. I would suggest the later to those of you who value challenging environment, don't fear changes of rules during the game, and who is a good negotiator.

Should we care about certification?

Ceritification is one of things that cause a lot of flame. Some people say this is critical to have a proof that your knowledge and it helps to find the job. Others insist that managers learned to be suspicious about certification value because theoretic knowledge it provides is of little help to day-to-day work.

I myself is rather of the second type of managers. I ground my conclusion on the fact that the best testers I worked with were not certified. On another hand, I know average professionals having tens certificates.

Of course, when comparing two idetical candidates (which is a very rare case), I would pick one with a certificate. So, the certificate wins but with a very small (insignificant) lead. This means that you need to think twice before investing into certification.

Management style: directing vs. controlling

Today I am in the mood to talk on a high matter - management.

I was managing a team of software testers for about 10 years and learned management from both ends: as a manager and as a subordinate. My manager side has learned that we are not as perfect as we may seem to be, so there is always things to learn from our more successful colleagues. My subordinate part observed a lot of mismanagement errors on the side of my bosses. Both kinds of experience allow me becoming a better manager myself.

Analyzing my own mistakes helps me avoiding them in the future. Watching mistakes of higher managers is a little bit thougher experience as it requires to get detached from theunpleasant emotions they cause and to observe the picture as if from the outside.

Management is not a science. This is rather an art. There are styles. Which style to follow depends on the situation on the managed project as well as on personal qualities of a manager. Methods that work best for one manager may be totally unacceptable for another. For example, strong egocentric leaders tend to adopt commanding style, while technical managers mostly use supporting style of management. The worst of mistakes is jumping from one style to another or having no style at all. It will look as if you act inconsistently and your people will have no idea what to expect of you, so they will be cautious andself- protective.

Part 1: Lessons of a manager

Below are some lessons I learned while being a manager.

Lesson 1: Be in touch with your team

In order to lead a team of people you have to feel them. You need to keep in touch with each team mate, to stay aware of what happens to the motivation level and what problems may prevent your people from feeling all right.

Managerial attention flatters people. They start feeling important and recognized. So, do not hesitate to stop by and ask not only about the status of ongoing tasks, but also about how they feel, what they did on weekend. Let them know that you care. I hope you do. Otherwise, you are on a wrong career path.

Lesson 2: Be informed and proactive

There is no excuse for a manager who does not know what happens on his project. Collect information regularly, summarize, analyze it and make correction to faulty actions timely. It will help fixing issues until it's too late.

Be proative and predict different kinds of situations, risks and contingencies. Have a plan for the cases when things go not as you wanted them to.

Lesson 3: Don't kill the initiative

Your primary goal is to provide the best outcome your team can produce. Some managers tend to achieve it by doing 200% themselves. Some managers control every action of subordinates strictly. Both ways are killers to personal initiative and responsibility. The people that are working for you are smart enough to take on decisions on their own (If they aren't then think if you have right people on the team).

It's ok that they make mistakes until they learn from it. Micromanagement is the cycle that never ends. People start thinking that their own thoughts are not needed and will wait for your command to take on every simple actions. Allow some freedom in decision making. After several (probably painful) mistakes you will get the team that can solve complex problems on their own.

Lesson 4: Don't push too hard

Pushing too hard is even worse than not pushing at all. Remember Newton third law and think twice before applying extra-pushing on people. All you may achieve is getting proportional resistance. Instead, try talking them into being your ally. Share the goal with them, make the goal their own.

Lesson 5: Trust but verify

Sometimes people lie. Have the means to check what you are told is actually the truth. In a while you learn who can lie and who is out of suspicion. After being caught on lie the former soon transform to the latter.

Lesson 6: Never commit to what you cannot deliver

This is the hardest part of management to me. I am a very optimistic person and I believe that there is no limits to possibilities for a team of professional. Probably, if the entire team was of such people, who simply forget about the other entire world when they see an interesting challenging goal it can do.

The reality is a bit different. Every team has capacity, throughput that cannot be exceeded. Committing to the task that is out of possibilities of your team is damaging to your image and career. I know that sometimes you are pushed to commit to the goal you don't believe in. Well you always have a choice...

Lesson 7: Foster a good friendly climate in your team

Healthy atmosphere boosts productivity. There is unnecessary friction. Peers willingly help each other to be successful. Communication is open and honest. Problems are made visible early, so you have time to react. Everyone is interested in self-development. There is a healthy level of competition within the team.

Part 2: Lessons of a subordinate

Now let's talk about what I learned to be the worst mistakes of my managers.

Harsh lesson 1: Inconsistent management

If you change your mind to often without justifiable reason people stop believing what you are saying. When they do, you cannot effectivelly manage them anymore.

I was told many different things by my managers, which I learned to be a lie. I was so frustrated that I stopped listening to what they say and started finding self-motivation in what I do. Not evryone can do this. Other people may simply allow their motivation to sink below the productive level.

Harsh lesson 2: Emotional management

Emotions indicate that you have lost control of yourself. Losing control is not the best thing because you hardly know what you are doing in such conditions. You may easily abuse someone and switch them into resistant attitude. In any case it will only make your management task harder.

I had a manager whose behavior was very dependent on the mood. He could shout loud at a person in the presence of others. This was simply devastating to the team attitude. Mostly it happened on Monday what made me believe that he had troubles at home. Anyway, your personal troubles shall be left off the doors of an office.

Another one liked to make harsh faces and to talk seriously". This was ridiculous. He looked like an idiot. Always remember that people sitting against you are smart enough to "read you".

Harsh lesson 3: Whishfull thinking

Wise men say "In order to learn how to speak you have to learn how to listen". Do not simply discard what you see for the reaction on the goals you set. Even if you want that deadline more than anything in the world, do not let this feeling to react on how you treat people who are going to work on it. Probably, you simply do not get the complete difficulty related to the task. Do not push because sonner or later people may agree with you being personally not sure that it's possible.

If you cannot suggest the way around the problems you have been reported do not simply put the responsibility and blame on your subordinates. Do not let them feel guilty because they cannot invent something completely new to achieve the goals you set before them. Instead, try to motivate them, give them your support, and recognize their achievements. They simply cannot provide more than they can! If you think they do then you are that kind of managers they mention in the anecdotes.

Harsh lesson 4: I am boss - you are fool

Do not pretend you are smarter than people who work for you just because you’re a boss. Most probably they are even technically more experiences than you because they do that kind of things every day. So, do not let only your voice speak. A good manager makes people saying.

I had a manager who _loved_ to speak. He was so enthusiastic about it that could never imagine how boring it was. It was a complete waste of time for those who listened.

Harsh lesson 5: This is them!

If something goes wrong have a nerve to take the responsibility. Report that you under-managed the process so it failed and take the blame. The worst kind of managers are those who start looking for the reason of failure in subordinates and finger-point to their own people, whom they hired and for whose performance they were responsible. This is so shortsighted. Believe me; this is obvious to your managers that you are trying to get out of responsibility. And they will not tolerate a manager who cannot bear responsibility. Think about that.

Harsh lesson 6: Having no idea what it's going on, yet make on decision

This is another though experience of mine. One day a big boss came to me and asked why we did not achieve our goals in test automation. I told him the difficulties we face on the way and how we decided to deal about them as well as presented my projections on which goals I can admit as reasonable. He was not happy and asked me if a problem was in a lead person. I was simply stunned because that guy worked as hell. He was the heart and the nerve of the project. I was so amased that I could hardly find the right words. Then I simply said my strict "no".

I was amased by how detached my boss was from what's actually going on on the project. However, he feels so sure of himself that tried to take on such a critical decision having lack of information. I would not call it smart.

Harsh lesson 7: The truth is out there...

One of the top managers I knew one day came to me and said exactly this "Vladimir, you are a good guy, however I do not see so much energy in what you do any more, so we decided to let you go." In that very moment I figured out why I did not trust that person before, why I hesitated speaking frankly to him. He did not tell me the truth that time. I figured it out later and it was not easy. The story was completely different from how he explained it to me. Why did he so? Because he did not care! He simply went the easiest way. He had no nerve, no courage to say the thing as they are.

Be honest. Say the truth. No matter what it takes of you to say it. Even if it reveals your own managerial mistakes, have the courage to admit them and to learn from them. Even if you are a big-big boss you still have things to learn. If you don't think so, you will never climb higher than you are now.

"A single lie destroys a whole reputation for integrity." - Baltasar Gracian

This is enough for today. I have to get back to work. I will write more on management later, when I have time and inspiration :)