One more feature please ...

How can you get discipline to not have feature creep? How can you decide when it is appropriate to change your plans to accommodate a request? What can you do if your business depends on accommodating feature requests?

In many ways this goes back to the discussion about how important predictability is to your company. As I have said before, I believe it is paramount. It is how your sales folks know what they can sell and how customers can know what to expect and depend on it. Predictability as a priority allows your employees to stay focused and feel accomplished.

Unfortunately, we know the technology world changes quickly. Here are some basics you must do to even have a discussion about change later:

• Have an approved budget
• Have an approved roadmap
• Have a release definition and approval process

Once you have these things, then you can put in an exception or variation process. Without them, your developers and company will experience unpredictability and chaos.

You should develop an exception process that looks at the following:

• The business case for doing the feature
• The development cost for doing a feature
• The other things doing this feature will affect like schedule or resources or customer expectation
• Executive signoff

The major thing is to make a premeditated decision. There are almost always tradeoffs and your company needs good information in order to make those tradeoffs. Good executives will help make sure the right decision is made and minimize the number of exceptions they will entertain.

If you find that you are experiencing a lot of feature requests because of customer requirements or industry requirements, then you may have to firewall resources to handle them. Think top-down. How much of your development resource do you want to dedicate to handling these kind of requests? Allocate them and use managerial courage to not allocate anyone else. If you always dip into all of our resources, you will never accomplish the less tactical and more strategic goals. Get agreement from the stake holders like sales or professional services on the allocation. If this still does not meet the needs of the business, you may have to rethink your business model.

Change is good. Constant change is not.

More later ...

Employee Performance Reviews

You have to do them. You have to do them on time. You have to be honest and constructive.

There are a number of goals for reviews:

• Have better employees
• Make sure employees and managers understand each other's views on the employees performance
• Provide a basis for compensation and promotion purposes

The first goal of having better employees should be your primary goal. This is where you help employees understand areas in which they to improve and this is where you encourage good behavior that you want them to continue. This is where you document issues that may be a basis for managing unproductive employees from your company. This is where you help your company and the universe by telling your employees the truth.

I have had situations where employees have thanked me for being the first person who was honest with them. Some of those employees used these reviews as a turning point in their careers and in their lives.

Here are some basics for reviews:

• Keep reviews concise. It is easy to lose track of what is important in long reviews.
• Use examples. Do not bring up generalities. If you cannot find an example, skip the comment (good or bad).
• Get employee input. It is important to understand and discuss the difference in your perceptions about your employees performance.
• Get outside input. Make sure to understand whether an issue or strength is only recognized by you or is seen by others.
• Make sure that a review is not used as the first time you bring up an issue with an employee. You need to have regular discussions throughout the year.

Take reviews seriously. Remember when you were an individual contributor. Take care in producing them. Respect your employee by completing them on time. Reviews become the basis for discussions about compensation and promotions so they hit your employees in their pocket books. They also become a matter of self-esteem. Do not underestimate their impact.

Do valuable reviews. Make your team better.

More later ...

How do you handle the end-game of a release?

So you did everything right. You defined your product and acceptance criteria well. You focused on the task at hand. You followed good processes for design and development. Now you have hit code complete. How do you get from here to a released product? How do you manage your resources and schedule?

Everyone has their own names for various phases. So that you understand what I am referring to, let's start with some definitions (the following definitions explain what you should have at the end of each phase):

• Development: design, design reviews, coding, code reviews, test code development and test code reviews are complete. The features basically work and the tests have been run but bugs may exist. You have met the Alpha entry acceptance criteria.
• Alpha: All criteria for General availability are met. Ready for field test. Beta documentation is ready.
• Beta: All criteria are met and the product has been field tested.

At the end of Beta, the product is ready for General Availability. Some companies have a Limited Availability phase before General Availability to augment their field test. Many customers will not field test Beta. A Limited Availability Release provides a production product with expectations that the product needs more field exposure.

The aforementioned phases occur regardless of what you plan or what you call them. Some people release final product to the field that I would call Alpha. The product still must go through the rest of the phases to achieve the stability expect in a released product.

Do not enter one phase until you meet the acceptance criteria for the previous phase. If you do, you will just be fooling yourself and slip later on. It is near impossible to make up time during these integration phases.

How do you size the time required for Alpha and Beta? A number of factors should be considered including:

• The number of features added to the product
• The amount of foundational change in a release
• The length of a QA cycle
• Efficiency of the team at addressing issues
• How complete the product is from the previous phase

This paragraph provides some guidelines for scheduling Alpha and Beta. If you have a product that can be robustly tested within a 7 day period and you introduce 10-30 moderate-sized features, then the Alpha time would be from 4-6 weeks and the Beta time would be from 6-8 weeks. For a larger product of 30-100 features, an Alpha cycle of 12 weeks and a Beta cycle of 24 weeks is more appropriate. Clearly the above factors will modify those times.

From here it is a matter of managing the test cycles, field test cycles and the bug list.

You must make sure that your test team has viable test candidates. Try to not sequentialize test (i.e. don't delay doing one test because another did not work). Make sure the test information is clear and concise. Report progress to the whole team. You should consider any bug stopping the test team from doing their testing, as the highest priority bug to fix.

Someone must drive field test. Start it as early as possible (even during Alpha). Make sure you are using your own products where possible. There is no substitute for real world testing. If you cannot accomplish this, you may have to do a limited availability release (see above). Make sure there is enough time to get feedback from the field test and incorporate changes. Send someone to customer sites to get them up and running quickly. Define what you need them to accomplish. Select your Field test sites well. Avoid using pre-sales customers as field test sites.

The final thing is the bug list. You need to agree upfront about what your criteria is. Do not wait until the end to negotiate this. Do not use Alpha or Beta time to fix bugs from the previous releases as they should have been scheduled during the Development phase. All releases have bugs. When you classify bugs, the only piece of information that is important is when the bug needs to be fixed by:

• Development complete
• Alpha Complete
• Beta Complete
• First Patch or Bugfix Release

Your product team including product management, engineering and support should help determine when or if a bug must be fixed.

You need to track the trend for your bugs. The three critical pieces of information are:

• How many bugs can your team fix per day
• How many total bugs are in the system
• How many new bugs your team is finding each day

With this information, you can determine whether you will make the schedule. You can also set goals about where you need to be during each week of Alpha or Beta. The product team can determine the cost/benefit trade-off for fixing each bug. If you cannot make the schedule, then you should ask your team to work nights and weekends to help try and get back on schedule. This is typical and should be expected for the integration phases of a release. If the trend continues, you will need to adjust the schedule to accommodate improving quality and you should examine your development practices so that you can do better on the next release. If you are experiencing a lot of bugs or as you get close to a milestone, conduct daily meetings with your direct reports or full staff as needed.

Once your release is stable enough to reach Beta, you need restrict the type of bugs you allow into a release. You must assume that any bugfix is as likely to introduce a new problem as it is to fix an existing one. You must also provide more restrictions and scrutiny on changes you allow your developers to check-in. More rigorous code reviews and management sign-off is common.

Finally when you reach a point when you have your golden bits that you wish to release, you must have rules about what to do between the time you ok that release and when it gets into customers hands. You will always find one more thing you can fix. So create a rule that says any bug found after the release is signed-off must go into the first patch or bugfix release (unless you would have stopped shipment for the bug in an already released product).

It is easy to slip releases in Alpha and Beta phases. There are always exceptions to the above process but you should remain focused, watch things closely and adapt.

More later ...

How do you address unproductive employees?

I just read an article by Scott Reeves at Forbes on this subject. He made a lot of salient points and the article is worth reading (click here to see article) but he missed a basic point: how do you make employees accountable?

Many employees confuse accountability with micromanagement. As Scott says in his article, micromanagement will never succeed. Employees resent micromanagement. Your team needs to understand that it is you job to produce predictable results. Your team needs to understand it is your job to get measurable status on a regular basis for all employees. Sounds like micromanagement right? Well the difference between accountability and micromanagement is in the process of getting the information and what you do with it.

Here are the signs of a micromanager:

• Ignoring pre-agreed to reporting points and asking status more frequently
• Getting mad at people for missing status
• Constantly changing working assignment
• Dictating implementation instead of requirements

You have to give people a chance to do their job in a positive environment. You need to look at problems as just things to be solved. You need to engender trust so you can get the truth when you ask for status.

Without an environment where there is accountability and trust, you will never help employees improve and you will never manage problem employees out of your organization. Every employee should know what tasks they should be doing. Every employee should know if they can go home at the end of the day or if they need to work harder. Every employee should have a schedule.

Employees should be involved in making their own schedules. Managers need to work with them where appropriate. Some employees are not experienced enough to develop schedules on their own but they should be involved in the process. Dictated dates are artificial and you will not get buy-in. You need employee buy-in to have reasonable accountability.

Once everyone has a schedule, you need to track it. At the beginning of a schedule, weekly meetings can suffice. At the end of a schedule during integration periods, daily meetings are often required. Do not expect everyone to be making their schedules on time.

From here the process of objectively identifying unproductive employees is easy. They are the ones who chronically miss their schedules.

Your number one goal should be to make them productive. Managing employees out and finding new ones to replace them is costly and it is worth some effort to try and turn them around. This requires a positive attitude on both the employee's and manager's part. If this fails, then the accountability based on real schedules will be an important piece of documentation in taking further or final steps. If it reaches this point, you need to follow your company?s policies carefully.

More later ...

How do you develop predictable schedules?

Let's go back to basics. I believe predictability is the main reason to have schedules in the first place (see my earlier post on schedules). The only way to get predictable schedules is to pick good tasks. So how do you pick good tasks?

Here are the basics on how to do it:

• Pick tasks of reasonable size (10 days maximum)
• Make sure the result is measurable
• Legitimize design time, test development time, integration time, etc.

If the duration for your tasks are too long, then you will not know your task is running late until it is too late. Slips in long tasks cause slips in releases. The only way to mitigate this risk is creating smaller tasks. This may require more scaffolding to test intermediate results. It may require longer schedules. If your goal is predictability, you need to tell your team that predictability is a priority for you and it is ok to identify shorter tasks, even if it results in a longer schedule. Longer schedules alone will not provide predictability. You need smaller deliverables.

Each task should have a measurable deliverable. Without a measurable deliverable, the schedule and the task are meaningless with respect to predictability. It is easy to create a task whose description is "Coded new APIs" but at the end what do you have? All you have is that code. Does it tell you that you are finished? Does it tell you it works? What if someone finishes the coding but it takes twice as long to get working? Identifying a separate integration phase does not help either because you cannot tell how far along you are. Instead I suggest a task description like "coded, developed tests, code reviewed and checked in 5 APIs". If the original goal had 15 APIs, then I would create three of these tasks (or whatever fits in 10 days). This sends a clear message that the task isn't done until it includes all of its pieces and is measured.

Finally, make sure that tasks include explicit time for design, code review, etc. It is easy to either slip because of these items or worse skip them. They are not the most fun tasks for engineers, so make them count. Without these items, it is easy to slip a schedule late in the game because of a lapse in up-front hygiene.

This is hard and your teams will need both practice and help to succeed, but it will payoff in success and rewards.

More later ...

How can you create urgency in the hiring process?

Have you had outstanding positions that have gone unfilled for long periods of time? Are qualified candidates going elsewhere?

The first thing you need to do is make hiring a priority. Next to budget planning (i.e. getting money to hire), hiring should be the next most important thing your team does. Without people, you cannot accomplish your goals.

Your team needs to understand they can, if necessary, slip other things to support the hiring process. Until they do and until you actually support that ideal, hiring will always remain secondary. It is much easier for your managers to spend time on fighting fires or working on products than hiring.

The second thing I would do is set goals for your team and hold people accountable. Here are some sample goals:

• Resumes reviewed per position per week
• Hires per month per manager (goal: 1)
• Time elapsed between identifying a good resume and a phone screen (goal: 48 hours)
• Time elapsed between a good phone screen and face to face interviews (goal: 48 hours)
• Time elapsed between good face to face interviews and an offer (goal: 48 hours)

Time allowed for candidates to accept an offer (goal: 72 hours)

Set goals for the above items with your team. I have place some goals I have used before in parenthesis above.

Another big issue that limits hiring is that many companies allow teams to have way too many people interviewing a candidate. I limit the number of interviewers to 4. Pick people you trust to do the interviews. Make it a priority for them to interview candidates. Make sure you get their input back quickly. You can support senior candidates who want to talk with more of the team but make sure to set your team's expectations.

Many companies are pennywise and pound foolish. They will negotiate every little piece of compensation to get someone at the lowest cost. In the end, you may leave a bad taste in a candidate's mouth. Even if they hire on, they may resent the process. It also takes a lot of time in the process. And, in the end, it costs much more if you lose a candidate.

So with all these techniques to increase urgency, how do you make sure you are hiring good people:

• Learn which members of your team are good interviewers
• Do reference checks (blind ones too if you can)
• Train and manage new employees well
• Don't be afraid to manage out mistakes quickly
• You can make a positive difference in how your team hires!

More later ...

What are the key factors in good morale?

In my job as a management consultant, I get asked to lead teams that have been through some amount of trauma including management changes, layoffs, missed schedules, etc. I am always asked about their morale and what we can do to improve it. The following is a list of basics:

• Improved sales
• Having a job
• Interesting work
• Communication
• Accomplishable tasks

There is nothing that helps morale more than a company that is doing well. Everyone wants to be on a winning team! If employees can see path to continued employment, R&D expansion and increased remuneration (stock and/or salary) then that is a great incentive. Note that success can be a two way street because there is a natural ebb and flow of employee movement. If a company is doing real well it is unlikely that movement will occur and it will take closer management of your employees to make sure people are not just hanging on.

Following 9/11, many developers were laid-off one or more times. Developers took lower salaries just to have a job. For many engineers this was the first time in their careers that they were out of work for any substantial amount of time. Stability rose as a priority in job seekers. While the environment has gotten brighter recently, the memory has not been forgotten.

Engineers may go to a company or stay at a company for the quality of work. The art and science inspire and compel many high-skilled developers to join or stay with employers. If all you have is maintenance work for your employees, do not assume they will stay even if you incent them. Incentives (bonuses, increased salaries) work for a while but not in the long run.

Employees can put up with a lot of hardship and change if they feel they are part of a team. The first way to make them feel like they are part of a team is to let them know what and why things are happening in a company. Communicate often and make it two-way communication. Solicit employee ideas. Explain rationale. The more you can share the better. Make sure you have a plan or a plan for a plan when you talk to employees -- ambiguity does not inspire confidence.

Finally, the item that is the lynch pin in morale, success, and satisfaction: accomplishment. If employees have impossible goals and they can never make those goals, they will always feel like failures. All good things in a company stem from accomplishment. If engineers can accomplish their tasks, sales has a chance to sell product, the company has a chance to make profit, employees get to make some money and do new exciting work. It ties it all together and it just feels good to accomplish something!

Go out and accomplish something with your team!

More later ...