Posts filed under 'Development Teams'

10 Ways To Insure Project Failure

Captain Bligh - A great navigator but a bad project managerIf you want your next software development project to fail, and not just a small way but in big, spectacular, way, here are some sure fire steps for you to follow:

1. Set Unrealistic Goals

Your management says the project has to be done in 2 months. You know it can’t be done in any less than 6 and it’s probably more like 9 months. But, hey, they want it in 2 and you’re in no position to challenge them so why not just go ahead and agree to it. Your team won’t mind. After all, if they agree to work 80 hours a week they should be able to pull it off. Besides, you’ve just gotten the purchase of a brand new code generation tool approved. This will save loads of time in the project.

2. Staff Up Quickly

You need people on your team ASAP. Hire the first warm bodies your pal at Programmers-R-Us sends over for an interview. Your project has a tight schedule so you need somebody, anybody, on-board and ready to code. Don’t bother with having your team participate in the interview process or be too picky. If you do, you might lose the good candidates to other companies.

3. The More Documentation The Better

Require your team to document everything. You need a scribe to take down the minutes of each and every meeting and publish them afterwards. Every form must be filled out according to a mandated template taken from an antiquated mainframe methodology you learned in school or a NASA software development handbook you bought on eBay. Insist developers write out weekly, or even daily, status reports. You can never have too much data about a project. Ignore the whiners on your team who complain about being overloaded with useless work. They just don’t understand the benefits of good documentation.

4. You Can Always Make Up a Schedule Slip Later in the Project

If your project is falling behind it is always safe to assume that you can make up the difference later. People were just goofing off or getting into the project at first. Everybody knows that as the project progresses everyone gets more comfortable and productive. Just like in a distance race, everyone stores up enough energy for a big sprint at the end. Count on having a strong finish for your project.

5. Relax Your Standards To Shorten the Schedule

OK, so it looks like the document everything plan is not going to work out so well. The obvious answer is to do the opposite, scrap all documentation including any end user instructions or help files. That extra work can be done after the project is completed. Also, cut out fluff like integration and user testing, well managed source control and test systems and your other standard coding processes and procedures that just get in the way. Quality isn’t important, only completing the project on time is important.

6. Micromanage

If left to their own devices team members will goof off. It is your job to stay on them 24/7. If traffic is bad one morning, make a point of calling late team members on their cell phone every 2 minutes to gauge the progress of their commute. Who knows, they actually may be lounging at Starbucks rather than sitting in their car behind a jackknifed semi. Call them in the evening at home as well, particularly if they have the audacity to leave early, to discuss fine points of the project for 30 minutes or so. Use time management software to track each developer’s time in and out of the office and exactly what they’re working on throughout the day. Also, you should swing by every team member’s cubical 2 or more times a day to ask them about their progress. Feel free to offer your sage suggestions about whatever they’re working on. This lets them know how much you care.

7. Call a Daily Project Status Meetings

You should have at least one daily meeting to take the pulse of the project. This is best scheduled either first thing in the morning or very late in the afternoon. This helps insure everyone is arriving on time and not leaving early. Better yet, schedule a meeting for both times for a win-win situation. Every point of the schedule and the day’s work should be discussed in detail during these meetings. You have the room and the team’s attention for a full hour so why not use it to the fullest?

8. Threaten Team Members to Motivate Them

If your team is falling behind the problem is that you aren’t motivating them enough. You’re allowing them to goof off and fall behind! Put your project back on track by putting their feet to the fire. Let them know that if they don’t dedicate themselves wholly to the project they’ll be finding a new job. Question their competence as programmers and mention how anyone who doesn’t perform up to standards will be fired so as to spur them on to greater acheivement. You will be amazed at how motivated your team is after you take this approach.

9. Bring In More Programmers

That Brooks guy’s ideas might have applied way back in 70’s at IBM but they don’t apply in modern, Web 2.0, times. Screw the ‘Mythical Man Month’. Bringing in more programmers means more people coding and thus more getting done faster, simple as that. You could even have them work shifts using the same computers to save office space and equipment costs. You can easily find or invent a buzz word to describe what you’re doing to sell it to the team and your management. What a brilliant coup that would be!

10. Set Your Plan in Stone

Never, ever, back down on your vision of the project schedule or plan. You said 2 months with the new tool and you meant it. You know you have awesome estimation and project management skills. Don’t entertain any complaints about your choices in meetings. Anyone questioning your decision is being insubordinate and disrespectful and probably just looking for a way to slack off. How dare they question your competence and authority?

Special Bonus Idea

If you need good political cover for implementing these steps toward failure you need to tie them to a popular development and project management buzzword like Scrum, Agile, or Extreme Programming. All of these methods offer excellent cover to you both during and after the project. This shows your managers that you’re on top of the latest software development project management trends while your team are a bunch of disloyal whiners who can’t stand to have their cheese moved. Furthermore, when the project fails you will be recognized as a company expert of the method since you know what doesn’t work. Does it matter that you just ‘cargo culted’ these methods? No, not at all. You’re well on your way to being the next ‘pointy haired boss’ or Bill Lumbergh.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

6 comments August 19th, 2007

The Basics of Tiger Team Programming

tiger teamTiger Teams often refers to a team of specialists who penetrate security systems on their side in order to test them. It also is used to refer to an ad-hoc team pulled together to solve a particular crisis or thorny problem, such as the team NASA flight director Gene Kranz put together to deal with the Apollo 13 explosion. In this article, we’ll examine how you can put together a problem solving team within your organization.

Why ‘Tiger Team’?

Many IT organizations have support group within their development section. However, most have unappealing names like “Internal Support” or “Operations and Processes Support Group” or some other decidedly unexciting name. By giving this kind of work a dull name, particularly one with support in the title, it generates the perception that the work is dull and perhaps even dead end. Using an exciting name for the work spices up the assignment and sells it better within and outside the organization by adding prestige, importance, and maybe just a little mystique to the assignment. You don’t have to call it tiger but at least use something that builds excitement and doesn’t drain it away.

What Does A Tiger Team Do?

The job of this team is to take care of short term, high priority, projects and problems that always seem to come up. For example, while you’re working on a new release, a critical security flaw shows up in the previous release. Rather than going into a panic and pulling people off the new work in a disorganized fashion, the tiger team goes into action and fixes the problem. Another example would be if the accounting department needed a quick set of reports for investors, the team could put them together quickly. The idea is for this team to provide a quick solutions to unexpected scenarios.

Another use for this kind of team is to provide support to an existing project team. An example of this would be if the project team needs to have additions and changes made to the source control system ASAP. The tigers could step in and take care of it without taking the full team off course. They could also do things like bringing new programmers up to speed and other such things that would take primary project programmers off their assignments.

In general, the assignments should not be any longer than 1 to 2 weeks (preferably even shorter), not involve more than 1 or 2 people, and should be very limited in scope.

Who Should Be On A Tiger Team?

Many organizations have downtime for members between projects. These people are ideal for tiger team assignments. If you don’t have a lot of downtime in your group, pick one person as the tiger on each development team along with one alternate. This allows team leads and managers to factor this into schedules and lets the person with this assignment know that they may have to switch gears from time to time.

Another key factor is to rotate this assignment throughout a development team and base assignments to it on personal work preferences. Bear in mind that some programmers thrive on this kind of work while others dislike it. Some programmers welcome a change of pace from a current project while others find it an annoying distraction. Take this into account. While everyone should take a turn at it, know your team’s preference and juggle your scheduling of this assignment accordingly, perhaps giving those who enjoy it more of these assignments than those who don’t.

If done wrong, assignment to such a team can be seen as punishment and thus become undesirable and unappreciated work. For example, keeping people assigned to doing this kind of work long term without assigning them to a full sized project generally isn’t a good idea. Many programmers will find this demotivating. However, when done right, it can be a positive recognition of a team member’s contributions to the organization and provide critical cross-training within your group. Make sure that you provide as much genuine praise for those who do this kind of work as you do to those working on full sized projects.

Your Thoughts

Have you tried tiger teams or other similar groups within your organization? What was the result? Do you have any other observations about the article or ad-hoc teams? Please leave a comment and let me know.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

2 comments August 12th, 2007

Marine Corps Leadership Secrets - Part VI

USMCThis is the last article in my series on applying United States Marine Corps leadership traits and principles to software development team leadership. In this article, we’ll look at some of the principles of leadership where the traits are put into practice.

Here are the other parts of this series:

Know Your Team and Look Out For Them

As team lead, you need to know what the strengths and weaknesses of each team member are. For example, if one person is strong on writing backends and another is strong on UI, assign them to tasks that play to their strengths. If you need to cross-train members, put a strong member with a weaker member. The better you know your team, the more effective they will be. Likewise, if you don’t know or ignore team members capabilities and preferences, you will soon run into difficulty. Use your judgement to make the right choices for you, your team, and your organization.

Also, watch out for your team’s welfare. If a project sponsor insists on your team developing a 12 month project in 6 months, have the moral courage to stand up to them. Don’t just roll over and let your team suffer under an unrealistic schedule.

Keep Your Team Informed

In the Marines and Navy, scuttlebutt was originally the term for a cask of water. Of course, as men drew water they talked and thus the term came to mean exchanging rumors and gossip. The ‘water cooler’ rumor mill is strong in some organizations. As a team lead, it is your job to make sure that you keep your team well informed about your organization and that they aren’t depending on rumors. Playing “I’ve got a secret” with your team is a sure way to damage morale. Have the integrity and dependability to keep your team correctly informed.

Certainly, there will be times you have confidential information. In those cases, show your loyalty to your organization by keeping it secret. However, you should also look out for your team in this case, particularly if the news is bad.

Set Goals You Can Reach

How many team leads have gotten into trouble by agreeing to schedules that they couldn’t keep? A lot, I would wager. It is your job to only accept work that your team can accomplish within the time frame given. Read up on project estimation and negotiation tactics to help protect your team from futile death marches. Your team may be good but don’t ask the impossible from them. Likewise, giving little make-work assignments one after another to a team of crack developers will frustrate them. Set the right goals for your team.

Make Sound and Timely Decisions

Knowledge and judgement are needed to make a sound decision while initiative is needed to make it a timely one. If you’ve made a bad choice, have the courage to change it before more damage is done. While you should avoid changing your mind frequently, sticking with a failing plan or development tool decision will only bring more trouble upon you and your team. Part of making good decisions is knowing when to make a change and when to stick with it despite the odds.

Know Your Job

Honestly, if you don’t know programming well you really don’t need to have a team lead job. This should go without saying but many organizations promote faces and personality over technical skills. As a technical team lead or IT manager it is your job to stay informed on the latest trends. You don’t want to be the kind of manager who says something like, “Oh, Ajax, I clean my kitchen with that” or “Orcas? Yeah, I saw one of those at Sea World.” Instead, you want to be in the know on all the latest trends.

If you don’t know, then have the courage to admit it. Don’t try to fake it in a ‘pointy haired boss’ fashion. Instead, learn from your team when you can. This not only improves your knowledge but improves the morale of the team too.

Teamwork

Encouraging teamwork seems like a no-brainer, doesn’t it? However, I’ve seen a number of teams fail because of interpersonal problems, cliquish behaviors, backstabbing, work hogging or avoidance and other such problems. Make sure that the people on your team are getting along. If they aren’t, find ways to help them deal with each other and, as a last resort, find a way to restructure your team. Ignoring these kinds of personal problems will only make things worse for your team. If you find one member is hogging all the work or avoiding taking on work, make an effort to better distribute the work. Whatever you do, don’t entertain gossip about a team member from another team member. This is a major morale killer.

Also, try to schedule social time together for the team. This might be as simple as lunch or drinks after work as a team once a week or so or something more elaborate on a less frequent basis. Be careful not to exclude some team members from these activities and try your best to schedule them in such a way that everyone can attend easily. While people may not show it, being ‘disinvited’ from such gatherings can be quite a morale killer.

OK, that’s all for this article and the series. Let me know if you liked it or have questions by leaving me a comment.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

2 comments August 11th, 2007

Marine Corps Leadership Secrets - Part V

USMCIn previous articles in this series on applying United States Marine Corps leadership traits and principles to software development team leadership, we’ve looked at the leadership traits. In this article, we’ll look at some of the principles of leadership, ways to put the traits into practice.

If you would like to read the other parts of this series:

Take Responsibility For Your Actions

As the leader of the team you are the one responsible not only for your own performance but that of the team as well. If your team makes a mistake, you are the one who is accountable for it. You don’t pass the blame on to a subordinate. Nobody above or below has much respect for a leader who does this.

You’ve been given the authority to manage the team so exercise it using the traits of judgement, tact, and initiative. Have the moral courage to be loyal to your team and your organization. Ultimately, your goal is to be responsible for success, not failure, so use these leadership traits to bring in a successful project. Even if things don’t always go 100% according to plan, you can still extract a degree of success through good leadership.

Sadly, some organizations may not give you a lot of authority as a team lead. In a situation like that it can be difficult but do your best using what little you have to bring about positive results. That too is good leadership.

Seek Self Improvement

I’ve seen a number of people allow their technical skills to deteriorate as they moved into a lead or management role. This isn’t a good thing. Even worse, they don’t make an effort to improve their leadership and management skills. Don’t be that kind of person. Instead, choose to stay current with your technical skills while improving your project management, general business or other related skills.

Take the time to examine where you’re at to see if you measure up. If you find yourself lacking in any area, seek to improve it. If you honestly think your skills are up to date and strong, seek new areas to learn about. For example, if you know VB.NET well, spend some time learning C# or Java. If you know project management, learn some accounting methods. Just don’t stay static.

Set the Example

A big part of leadership is setting the example. This not only applies to how you do your work but the way you do your work. Which do you think will inspire your team more, coming into work late, half doing tasks and making excuses or arriving on time or early, doing excellent work and taking responsibility? When it comes down too it, setting a strong example does more than any instruction or discipline will ever do.

Ensure That Work is Understood and Completed

A common problem in software development projects is poor communication. If your team doesn’t understand what is to be done, it is likely that what they do won’t be right. As the team leader it is your responsibility to see that the work to be done is understood by all. If there are missing pieces, it’s your job to seek them out from your management or project sponsors. It is also your job to clearly communicate the project goals and timeline to the team. They’re looking to you for this information and if you don’t provide it, you’re almost guaranteeing something will go wrong.

You’re also responsible for seeing that the assigned work is being done correctly and is moving toward completion. However, you don’t want to be a micro-manager. After all, these are supposed to be professionals you’re working with, not ditch diggers. Avoid asking for daily status reports or (shudder) holding daily staff meetings. Instead, use email, source control, and other tools to keep an unobtrusive finger on the pulse of a project. If you note a problem, quietly take it up with that team member in a positive manner. You’ll find this approach puts you in closer touch with the status of a project than any make-work status report ever will.

That’s all for this part. I’ll be wrapping up this series in the next day or so when I go over a few more principles of leadership. If you have any questions or comments about this series, please feel free to leave me a comment.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

3 comments August 6th, 2007

Marine Corps Leadership Secrets - Part IV

USMCIn this fourth article in my series on applying United States Marine Corps leadership traits and principles to software development team leadership we’ll be looking at the last 4 leadership traits: Endurance, Unselfishness, Loyality, and Judgement.

You can read Part I here, Part II here and Part III here.

Endurance

Physical endurance plays a big part in the Marines but mental endurance is also important and that’s what we’ll concentrate on here. Endurance is defined as the ability to sustain a prolonged stressful activity. While you probably won’t be leading any 50 mile forced marches we’ve all heard software development projects referred to as ‘death marches’. Quite often a project can become a stressful mental exercise and, in some cases, a physical one as well as long hours are worked. Your ability to endure this misery will test your team leadership ability.

As a team leader the rest of the team will be looking to you to help get them over the hump on these tough projects. If you slack off, what do you think the rest of the team will do? They’ll follow your lead. If you decide that extra hours or even an all-nighter is needed, you’re the one toughing it out to get the job done, leading by example. I’ve known mid to upper level IT managers who’ve worked through the night and into the next day to fix a problem, helping when and where they could, and I’ve also known some who thought making it to the country club early on a Saturday was more important than being in the office for a weekend release. Can you guess which ones I respected as a leader more?

Unselfishness

It is a Marine tradition that in a chow line the lower ranking Marines are served first, then the squad leaders, then the staff non-commissioned officers. This is unselfish leadership in action. How can you show this kind of unselfish leadership in your role as a team lead?

An unselfish leader doesn’t grab all the perks for themselves. Sure, you’ll get some of these due to your position but you don’t need to flaunt them. One good example would be the computer system you’re using. If you have a top of the line system and the rest of your team is struggling by on poor performing systems, how do you think they’ll feel about that. As tough as it may be to you, make sure that your team is well supplied with the tools they need to do their job before you are. If you shortchange them, they’re likely to return the favor.

Another key area is in giving and taking credit for work. Nobody likes to work for a manager who takes personal credit for someone else’s achievements. You should always recognize the hard work and great ideas of your subordinates both to them and their peers and to your management as well. Not only does this behavior make them look good but it makes you look good as well.

Loyalty

The Marine Corps motto, Semper Fidelis, a Latin phrase meaning ‘Always Faithful’. This phrase embodies the loyalty Marines have to each other up and down the chain of command and even after they leave active duty in the Corps. Loyalty is a two way street and your words and actions should always reflect your loyalty both your team and to your managers. What are some ways you can show loyalty?

One is to back your team when they’re right and tell them they’re wrong when they’re wrong. A poor team lead will tell the team one thing and their management another and thus, show disloyalty to both. Sometimes it takes moral courage to be loyal in a situation. Have the courage to be loyal.

Another opportunity to show loyalty is when you pass on orders to your team, particularly ones that are distasteful. Don’t be disloyal by blaming the person above you for the situation. To do so only weakens your standing with the team. If you can’t change the situation, make the best of it. If it is something you can fight for, do so. Either way, it’s being loyal to your team and organization.

Never criticize your company leadership or your management peers in front of your team and discourage your team from doing the same. Nor should you allow gossip about personal lives be passed around. Stay loyal to your company and to your team by avoiding this trap.

Another way to show loyalty is to help out your team members if they’re having a problem, personal or professional. Hopefully your company isn’t a real world version of a reality show where you get points for throwing team members under the bus when they’re not up to par for some reason. Instead, help them out. By showing your loyalty this way they’ll have greater loyalty toward you, the team, and the company when the situation has past.

Judgement

Our last trait, Judgement, is all about applying the other leadership traits and your experiences to make the best decisions. You should avoid thinking rashly and, instead, think through a situation so that you can make a good decision.

Of course, there will be situations outside your experience. In the best cases, you will have someone else you can rely on to give you the benefit of their experience in your organization. This could even be someone who is technically junior to you within the organization but who has more experience there. If there isn’t anyone available to you, which is not the best of situations, you may have to rely on sources further removed or even a book or article. But, if you need help, seek help. This too is good judgement.

That covers our discussion of the leadership traits. Next in this series we’ll be looking at how to apply these traits. As always, feel free to leave a comment or question if you have one.

Here are the other parts of this series:

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

2 comments July 31st, 2007

Next Posts Previous Posts


Visit Me At My New Site, Programming In C#

Most Popular Articles

Highest Rated Articles

Categories

Most Recent Articles

Feeds

 Subscribe in a reader

To subscribe by e-mail
Enter your address here

Delivered by FeedBurner

VB Opportunities

Archives