Monday, December 18, 2006

IT common role anti-patterns

Text of this article is a quote from An Agile New Year's Resolution for All of Us by Scott W. Ambler, Dr. Dobb's Portal, December 15, 2006:

I think that if you spend a few moments to reflect, that you'll agree with me that you've seen, if not exhibited yourself, one or more of these common role anti-patterns:
  • True Believer. Also known as the "Born Again Developer," a True Believer "just knows" that their preferred approach to development is the best one and is very happy to let everyone else know it. The True Believer rarely seems to question what they know to be right, and strangely enough often struggles to justify why it's right. A better approach is to be open-minded but skeptical at the same time, recognizing that no approach is perfect and can always be improved upon.
  • Mind Reader. In the middle of a discussion a Mind Reader will state what someone else must obviously be thinking. Strangely, Mind Readers only seem to pick up on negative ideas, or at least ideas which very clearly cast the other person in a bad light. A better approach is to ask other people what they're thinking instead of guessing; in other words, actively seek to communicate with one another.
  • Hypocritical Preacher. A Hypocritical Preacher says one thing yet in practice does something else. For example, it's very easy to preach about the virtues of open and honest communication, or to promote collaboration with and respect for others, but it's a completely different matter to discuss ideas with those same people when their ideas are very different from your own. It's also very easy to preach about quality, yet not so easy to fund, develop and then support an automated, end-to-end testing environment. The solution is to practice what you preach, and if you're going to preach to only do so about the things that you actually practice.
  • The Spammer. Need I say more?
  • Unjustified Criticizer. An Unjustified Criticizer will often criticize something without having read it, often because it's about a topic which goes against their true beliefs or because it's written by someone they have disagreed with in the past. Unjustified Criticizers are easy to identify because they provide insufficient arguments to support their criticism, in fact they often make blanket statements and then refuse to justify those statements, and rarely seem willing to share their actual experiences pertaining to the topic (usually because they have none to share). The solution is to describe your own relevant experiences and then ask them to comment on them. You might not get an answer, but at least you'll provide others with a viewpoint based on fact.
  • List Dictator. List Dictators are often Hypocritical Preachers, True Believers, and/or Unjustified Criticizers who find themselves in a position of power. A List Dictator will often define exactly what can and cannot be discussed on the list, but will often choose to flaunt those rules themselves as they see fit. In the extreme, List Dictators will often ban people who they feel are dissidents instead of publicly addressing their issues in the discussion forum. By limiting the discussion, List Dictators attempt to prevent others in a discussion forum from questioning the dogma which the List Dictator wishes to focus on, thereby promoting their agenda. To be fair, one benefit provided by List Dictators is that they often thwart the effort of spammers. Unfortunately there's little that we can do about List Dictators other than to try to convince them to behave more responsibly, otherwise we need to vote with our feet and create better discussion forums.
  • Unknown Poster. Unknown Posters typically have list names such as "Cyber Guy", "Agile Guru-Dude", or "Object-Data Architect". Cute nicknames, if you're a teenager living in your parent's basement, but they don't tell us who you are. Unknown Posters often seem to be True Believers who don't to have the courage to be associated with the ideas that they're espousing. The rest of us reveal who we are, and we should invite everyone within a discussion forum to do the same.
  • Indifferent Specialist. An Indifferent Specialist is someone who is often very good at what they do, be it Java programming, business analysis, or database design, yet they are rarely motivated to learn about things outside of their specialty. These people often underestimate the importance of these other things and in extreme cases will choose to denigrate these topics or the people who believe in them. Statements such as "Oh, that's something the programmers do" or "We need to blame management for that, they can be so dense sometimes" are indications that someone is an Indifferent Specialist. The solution is to strive to become a generalizing specialist, someone with one or more specialties and a general knowledge of IT and the business domain that they work in.
  • Backstabber. A Backstabber will criticize someone, or their ideas, but their victim doesn't know that it's happened because they weren't included in the conversation. The solution is to have the courage to involve the person that you're criticizing in the conversation so that they have an opportunity to respond: In the case of online discussion forums, explicitly copy the person on your posting if you're not sure that they're on the list. If you have a strong argument, then you shouldn't be afraid of a response, should you?
  • Blamer. Blamers are often Indifferent Specialists or True Believers who are a bit too arrogant for their own good. Instead of accepting responsibility for trying to solve a problem, they instead choose to blame others for the problems. Agile teams work together collaboratively and take responsibility for the project as a whole. If there's a problem, or if something isn't working well, it our responsibility. Blamers will promote division within teams, and in discussion forums, often to promote their own political agenda. The solution is to point out that we're all in this together and need to find a solution to the challenges that we face, and not to just push them off to someone else.

Thursday, December 07, 2006

Time Management

Time Management is a principal subject when someone talks about planning personal activities in the most efficient way. But, unfortunately, this topic is often being omitted when focusing on the management in general.

Isn't it a manager's responsibility to build her/his team work in effective manner?

It's not about creating 15-minutes detailed work plans for an each team member (I bet anyone can do it good enough even having only 2-3 subordinates). But, at least, a manager must help his team to understand what is expected, when, and how to accomplish it on time.

However, we've used to see the opposite in real life... Instead of helping employees to plan their tasks, to follow that plan, and to update it when required; their bosses help them to ruin their personal time management process. It's being done by forwarding unsorted tasks, by urgent report requests, by unplanned meetings, etc.


If you are a manager and want to have your team working effectively, it makes a sense to consider the following rules:
  • Set realistic deadlines based on the date when you really need to get the result, not just to make your team being in rush;
  • Do not schedule urgent meetings if it's not really required. Give your people some time to adjust their plans;
  • If you have to assign several tasks to an employee, make sure that you set the priorities.

Sunday, December 03, 2006

Change-Driven Development. Introduction

Have you ever taken part in a project, that wasn't affected by some extraneous factors being changed during the development? Probably not, if we do not consider paltry projects-tasks that take only few days from defining initial requirements till a final release. In every other case, regular changes are just a usual part of software development process in modern world.

However, despite the regularity of such changes, teams often turn out to be incapable of responding to new, clarified or updated external factors in time. As result, it leads to frustration of deadlines, and to trite excuses like: "it wasn't possible to meet the deadline because the customer was changing their requirements continuously" or "an extra month is required for new developer to gen up on the project". Familiar cliché? In many cases, these explanations are fair and they do really explain the reason of the failure. Alas, opening the reason just helps to smooth the situation, but not to solve the original problem, - developing the product on time and budget. The same way as it doesn't help to consolidate company professional reputation.

Realizing inevitability of changes, many companies already applied some management processes regulating a set of actions that need to be performed in a case of particular change events. Some other companies went event further, and introduced concepts to control risk of rising one or another specified change. But in spite of these precautions, factors that seem minor accumulate and finally influence the course of whole project, and essential events are often found to be amiss.

In some future posts, I'll describe an idea of adapting existing development processes in a way that is based on change perception as a natural factor settling a project flow - Change-Driven Development. Described method is admissible for most existing development processes. Simplicity of implementation and adaptation appreciably facilitates acceptance by team members. The result of application is achieving commercial project goals in the shortest term, at the same time, keeping the climate easy-tempered and stable. For its turn, the last does even more - it decreases turnover.