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!
Tuesday, July 14, 2009
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.
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.
Monday, July 13, 2009
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!
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!
Friday, July 10, 2009
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.
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.
Wednesday, July 8, 2009
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 ;)
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 ;)
Tuesday, July 7, 2009
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.
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.
Saturday, July 4, 2009
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.
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.
Subscribe to:
Posts (Atom)