Avoid Whack-a-Mole Development

Venkat Subramaniam
Broomfield, Colorado, U.S.

Software project managers

face a lot of pressure to deliver fast. Time is of the essence. How can you get things done fast?

Imagine you have two programmers on your team, Bernie and Rob. Both are capable, have the same amount of domain knowledge, and have equal language skills. During development, you find that Bernie finishes his feature implementations much faster than Rob.

While Bernie focuses on getting the code completed quickly, Rob spends time writing code and then refactoring* it. He names the variables and methods better. Once he gets things working, he breaks the code into smaller pieces. Now he writes tests to make sure each piece of his code does what he meant it to do. When he’s reasonably satisfied, he declares the coding of that functionality done.

But assume you don’t know these details. If you only look at the speed with which the functionalities are declared done, clearly Bernie is the better man, right?

A few weeks go by, and you demonstrate the features to your customer. As usual, the customer loves your completed features, but now wants you to change and improve them. You ask your developers to make those code alterations. When you take the new and improved functionality back to your customer, they try out the features that Rob implemented and are pleased with the changes.

Unfortunately, they discover something odd with the features that Bernie implemented. While Bernie has programmed in the new functions fine, now a few things that worked before don’t work anymore. The customer marks these as defects, and you ask Bernie to fix them. The customer tests the features again. Now even newer, stranger things seem to be broken. What’s going on here?

If you have a child, you know what is happening. Bernie has created a Whack-A-Mole application. Whack-A-Mole is a toy. Kids are given a wooden hammer to strike moles that pop up at random. It’s fun for them to be surprised by which mole pops up next. However, fixing applications with broken code popping up at random places is not fun. It is frustrating, unpredictable, and it slows your product development. Bernie was sprinting initially, but he was running in the wrong direction.

While Rob appeared slower at the outset, he was actually creating superior code. His pace proved sustainable. The better quality of his initial code helped him make workable changes quickly. Plus, the tests he wrote in the beginning gave him instant feedback regarding whether or not his new code was compatible with other parts of the application where the code was used.

When measuring time for a feature implementation, do not consider only the time it takes to write it in the first place. Add the time it takes to enhance, fix, and improve the code. Writing good quality code and tests takes time. It appears to be a short-term loss. However, it comes with a long-term gain.
Ask yourself if you want speed, or if you want to savor sustainable progress.

PMP - Delegation

PMs should delegate:

o Routines (to get out of comfort zones)
o Tasks that require technical expertise (to offer challenges)
o What someone else can do better (to increase morale)
o Some enjoyable things to others (to motivate)
o Tasks or challenges to vary the routine of those who have boring jobs
o Activities that will allow people to cross-train one another so that they can manage their day-to-day crises (to increase self-confidence)
o Projects involving the critical, visible issues of quality, quantity, cost and timeliness to self-managed project teams or self-directed teams

What should not be delegated:

* Long range planning (although you should involve others)
* Selection of key team players
* Responsibility for monitoring team’s key project or key function
* Task of motivating fellow team members (people value how much the leader cares for them)
* Evaluation of team members (performance appraisals)
* Opportunity to reward team members
* Rituals such as groundbreaking ceremonies and celebrations
* Touchy, personal matters, or crises
* Items that set precedents or create future policies

Guidelines for effective delegation:

* Explain why the tasks are being delegated and what is their relative importance to the project, larger projects and to organizational goals
* Establish mutually agreed upon results and performance standards related to tasks
* Delegate in terms of objectives rather than procedures. To encourage creativity, give people freedom to pursue tasks their own way (but establish parameters or limits)
* Give team members authority necessary to accomplish the tasks
* Ensure acceptance from the delegatee. Build team members’ confidence in the use of the delegated authority
* Provide continuous support, training, and guidance to assist in the satisfactory completion of delegated tasks
* Demonstrate your confidence and trust in the abilities of project team members by encouraging new ideas and minimizing their fear of failure
* Uncover any obstacles to delegation and develop a plan to minimize the effect of these obstacles
* Remember that people produce the best results when they are having fun and doing what they WANT to do rather than what they HAVE to do. Thus, when possible, delegate tasks on the basis of employee interests
* Facilitate team members’ access to information, people and departments that are not normally available to them. This will demonstrate the PM’s sincerity and confidence in team members and improve task performance