Showing posts from August, 2011

Risk Assessment after Hurricane Irene

Now that Hurricane Irene is behind us, and you've used your Crisis Control skills to salvage as much as possible in real-time, there's a natural urge to start Risk Assessment for the next natural disaster.

However, we cannot predict what the next surprise will be, since then it won't be a surprise. It's even harder to predict how much damage it will cause; nobody could predict the disaster and chaos caused by 9/11 - probably not even the terrorists who masterminded it - including Bin Laden himself.
Most of the time the size of the catastrophe is inversly proportional to the amount of preparation for it.
The trick is to break down the various troubles from the current disaster and group them into distinct categories. Each category then gets treated separately - and each category can be assessed for future prevention, if the risk/cost ratio is high enough. 
Here are some potential groupings - feel free to classify them differently. CommunicationInternet connectivityAccess to …

Give credit where credit is due

Typical amateurish management attitude: It's his job, after all. Why does he also need a pat in the back? He gets a salary!

Giving people credit and compliments makes them feel good. People who feel good work better. So the more opportunities you find for complimenting your team, the more you gain.

That's besides the moral aspect; true they are being paid, but if they achieved something they deserve the credit.

Credits can be given in many ways:

The "about" section can list all the team players; keep it alphabetic to avoid upsetting people.Patent applications can list all those involved, even if their idea didn't make the final cut.Progress reports can highlight those people who made a difference; rotate the names regularly to have everybody included.At company meetings make sure to mention a few people by name.But beware of adding a prize to the credit: If it's not substantial, then it may have the opposite affect:After all those extra late nights all I got was a…

Generic - too much of a good thing?

There's a delicate balance required between making code generic on the one hand, and hard coding everything on the other hand.

Making the code generic can make it easier to tweak things.

For example, if your footer includes a copyright and the year, then you can either hard code the year, and change it every January, or you can write some code to calculate the year, or you can have the code retrieve the year from some properties file.

Here the solution seems obvious; write some code to calculate the year, and never worry about it again. However, debugging this code may be more time consuming than a yearly trivial update.

If you want to be able to control the amount of ads on each section of the page, it's easiest to control this from a properties file. Then you do not need an engineer to update the code!

This seems obvious, but not always feasible. Sometimes the ads have some business logic behind them that would require huge amounts of code to handle a generic solution.

Another pro…

Prototype pitfalls

In software, a prototype seems to work like the finished product. In reality it's usually a pretty face (GUI) with minimal functionality.

If you actually try use the prototype you will discover that it only works for a limited set of actions, if at all.

My first introduction to a prototype was in the mid-1990's. My good friend Jack Kustanowitz arrived at Kivun (of Dagesh fame) as a summer intern. 

Netscape had just released the first Web Browser - and all you could do was browse. Maybe it also had a back button that went to the previous page.

Using Visual Basic, Jack created a prototype of WebTamer; everything your browser needed. Functionality like "History", "Off line browsing" and "Bookmarks".

And it seemed to work! Making a product out of it should be trivial, Project Management was assured. (These were the same non-techie Project Managers from yesterday.)

Suffice it to say that the road from Prototype to Release was long and painful, since the prot…

Why a technical Project Manager?

Is it important that a project manager understand the technicalities of the project she is managing?

In theory Project Management is all about scheduling; finding out what needs to be done, how long it will take, and tracking the results.

There seems to be no reason why the Project Manager needs to understand the technicalities of the project.

I have discovered that this is not so. A Project Manager who does not understand the technicalities, has no idea what she is doing.

Firstly, the team loses all respect for a Project Manager who cannot differentiate between a check-in, a compile and a debug session. As a result they have no problem hiding information from the Project Manager - a guaranteed recipe for disaster.

Many years ago, before I became a Project Manager, I attended the daily meetings of a project, as manager of setups (the installation program).

In the engineering department I was hearing them talking about rewriting the Kernel - that's a huge job and is like a heart transpl…

Eating your own dog food

Obviously if you make dog food you don't want to eat it - but you do want to make sure that your dogs eat it.

If you don't have any dogs, then maybe you are in the wrong business.

Why dog food? That's an old expression, which you can read about here.

If you have no idea how your product works in the real world, then you have no idea how people use it, what problems they have with it and which features they don't understand.

To overcome this you can run a beta-test program. Or you can invite people off the street to come and use it. Often the interaction is video-taped for future analysis.

An important step is to use the product yourself; you, your employees and their families. 

As strange as it sounds, many companies think that they are eating their own dog food, but they are not.

Having the techies use the product is a good start, but not sufficient. After all, they know all the tricks - what the magical shortcuts are and the hidden features.

They also know what not to use, s…

Too much of a good thing?

Since my current full-time job is to find a steady source of income, I have been spending a lot of time on LinkedIn.

It's a great tool for researching potential jobs, since apparently 70% of jobs come from connections. (Who needs protekzia when you have the right connections? J)

The concept is simple: Search for the company that is advertising an opening and discover who you know there - and then ask them to put in a good word for you.

What I noticed was that I had "1st level" contacts almost everywhere. That should be great, except that I would consistently discover that these were all people who had found me and linked up with me over the years - but I have no idea who they are.

Or else they were people who I had linked up with, as they worked at HR companies, or were famous people or vaguely connected to a company I worked at.

Bottom line: I do not know them. So?

So I cannot write them a note asking them to put in a a good word for me, as they have no idea who I am.

And beca…

To be wise or to be right?

Yesterday I was watching a group of kids trying to define an ad-hoc game. They had about 15 minutes of play-time at their disposal.

Most of the kids just wanted to play and make up the minor details as the game went along.

There was one girl who was strong willed and was insisting and defining every possible rule - and she had a strong opinion as to what those rules should be.

Result: They spent the entire 15 minutes defining rules. Not all of them; some of them left earlier in disgust and went to play.

There's a delicate balance between a fully completed  spec and a perfect one.

This is one of those tough calls that a Project Manager has to make. The spec most cover everything. Or must it?

My father tells the story of how the programs in his time - coded on punch-cards (!!!) were able to handle leap years - including the exceptional ones - like the turn of the century. Their systems were Y2K-proof.

After all, they had no idea that the world would progress past punch cards - so the date …

Setting priorities

In Agile development, milestones are typically 2 -3 weeks long and are called sprints.

Before each sprint, the team gets together and decide what needs to be done. Typically, the Product Manager will have a backlog of tasks from which to choose from.

Obviously, urgent tasks that will make a noticeable difference to income, traffic or user experience will get priority.

However, less-important tasks also need some attention, otherwise they will never be done.

The date at which a task was first presented to the sprint-prioritization meeting should be noted. If a task has been presented 3 or 4 times and is still in the queue, then a decision needs to be made:
Either do the task in the coming sprint, or delete the task.
If a task is simply being mentioned for old times sake, and everybody would like to do it but nobody has the time, and nobody can see the urgency, then it is simply taking up time in the prioritization meeting.

Since we live in a dynamic world, not every task can be planned 2 - 3 …

Stop starting. Start finishing.

When we started using the Agile development concepts at, we started by putting up a Kanban board.

We then created a post-it note for each active project.

Result? The board was not big enough and the concept of Kanban looked overwhelming. How were we supposed to track this many projects?

That's when we took the drastic step of stopping many of the projects we we re working on. We implemented the "Stop starting; Start finishing" philosophy.

Initially it was counter intuitive: We were trying to get more done by doing less?

Yes. That was the game plan - and it worked!

Instead of thrashing between multiple projects, each team was focused on a single project or milestone. More than that: we stopped using each team to its full capacity!

What? You had people do nothing?

No. Never. Worst case scenario, the spare people would take care of things link technical debt; those little annoying things that really should be done but nobody gets around to them.

Most of the time these sp…

RetroSpec: The quick long way

RetroSpec: The act of writing the spec after the code has been written.

For various reasons, sometimes it makes sense to first write the code and only afterwards to write the spec. 
For example: You may not be sure what is technically possible, you hope for at least some minimal functionality, but discover that it's trivial to implement a fully-blown feature.
Sometimes it doesn't make sense, but it simply happens; a quick fix or tweak turns into a feature. This could be the result of a programmer having a sleepless night and dedicating it to the cause, or a team having an internal competition.
Or it may simply be a case of feature-creep.
If it's already coded, why the spec?
If nothing else, QA needs to be know what to test, and without a spec that cannot know what is broken or purposely missing.
If you keep documentation up-to-date, then you will need a spec so that the technical writers have a starting point.
But the most important reason to RetroSpec is to enable a spec review. …

Scrum: Rugby or Project Management?

A scrum in rugby is a is a way of restarting the game and pits the 2 teams against each other in close proximity. It's one of the less gentlemanly parts of the game.

In Agile software development, a scrum is a daily meeting to sycn up all teams - similar to what I described in a previous post titled: Sync up in 15 minutes: The daily stand-up

The agenda of the daily scrum is always:

What has the team done since yesterday?What is the team planning to do today?Does the team have any problems that would prevent it from accomplishing its goal? The scrum is run by the Scrum Master - who is often also the Project Manager - and, as expected, it is the role of the Scrum Master to be in charge of finding solutions to any impediments that arise.
The reason I keep away from the term scrumis because of its rugby definitions. The daily meetings do not restart anything; most healthy projects do not time-out every 24 hours.The daily meetings don't pit the teams against each other. I prefer to thi…

Overtime and All Nighters

Mid-1990s: The Gold Master Disk had to be in Ireland by the following afternoon, if we were to ship on time.

This required us to work all night; I got home in time to see the sunrise, and was expected back at work after lunch.

I was there because each new build required a new setup - and I was Mr. Setups - in those pre-internet days when CDs were a novelty and all programs were installed.

We made it! The Gold Master Disk was shipped, thousands of copies were made, put in boxes with a huge manual, and shipped back to us.
By the time they had arrived, we had discovered some serious bugs and the entire shipment was declared unfit for use. When the company closed down a few years later, we finally threw the entire batch into the dumpster.

That was my first introduction to all-nighters, and the more I lived through them and watched the results of all-nighters and overtime in general, the more I am against them.

After 10 - 12 hours of work, most - if not all - people start being too tired to thin…

Any decision is better than no decision

Since the Project Manager is involved in keeping all the pieces of the project together, he is the natural address for questions.

One of the items that need to be addressed during the early stages of any project, is: "who is responsible for making decisions?"

However, many of the questions that arise do not have a correct/incorrect answer, the simply need a decision.

Examples would include:
What font size/color to useWhat exact wording to use (OK or Yes or Go)What happens in corner cases which nobody though of and probably never happenMost of the time the answer is not really important. What is important is providing an answer.

The sooner the answer is provided, the sooner the developer can get back to work.

A Project Manager needs to be courageous and simply make a decision. This decision then needs to be documented (so that QA know about it, for example) and then communicated to whoever was supposed to make the decision.

The only data the Project Manager needs is how long would i…

Emotions and Projects

Conundrum: Should a Project Manager be emotionally involved with her project?

A  Project Manager needs to consider her project as the most important thing happening in the world. It needs her entire focus and concentration.

The more she thinks about it in the shower and while falling asleep, the better chance of her coming up with ways to improve the project and to realize what is missing and to identify potential trouble before it becomes obvious. 

This is why it's best when a Project Manager has only a single project to manage, at any one time.

That said, the worst thing that can happen to a project is to have the Project Manager emotionally involved with the project.

Why? Because it's crucial that the Project Manager be able to make decisions based on data and not on emotions.

Once a Project Manager is emotionally involved in a project, she will not be able to make drastic changes; she will fight any attempt to change, shrink or otherwise modify the project, since she is now emo…

The Magic of Milestones

Project Managers talk a lot about milestones.

What are milestones and what do they do?

Milestones as per the dictionary are:
A stone marker set up on a roadside to indicate the distance in miles from a given point. An important event, as in a person's career, the history of a nation, or the advancement of knowledge in a field; a turning point.Or - closer to our discussion - Milestone or  key activity:
(industrial engineering) An activity that possesses major significance. Also known as milestone activity. It makes sense to break up a project into milestones, each milestone being 2 - 3 weeks long. At each milestone the team will deliver something. This allows the project to have points along the way (milestones) at which to be able to pause and check: What have we done so far? Is it what we want? How long did it take vs. how long we thought it would? What's left to do? How long will it probably take us? How does that compare to our original estimate? It's a also a good time to take so…