B - Balance Stakeholder's Priorities:  Projects always have more than one stakeholder, the first stakeholder that springs to mind is the business sponsor but IT is often a stakeholder as it attempts to ensure that the project aligns with standards and architecture goals, Accounting is a stakeholder as it measures the costs and presumably the benefits associated with a project, there could be Regulatory stakeholders who need to ensure that specific rules are adhered to.  Identify these stakeholders and ensure that their priorities are understood and balanced across the project.

C - Collaboration Across Teams:  One of the biggest failings of many projects is that teams don't work together, they simply create work products and 'hand them over the wall' to their counterparts.  Foster collaboration through shared goals/objectives, facilitated meetings, tooling and where possible colocation. 

D - Demonstrate Value Iteratively:  Rapid feedback is one of the most important ways to ensure that your project will deliver what its stakeholders need.  Emphasize 'value' by showing working software over documents and meetings as quickly as possible.

E - Elevate the Level of Abstraction:  Often times projects get bogged down in the minutiae of data tables, interfaces and technical design.  Understanding the goals of the project and abstracting to different levels of detail will not only make the project more manageable but go a long way to ensuring buy-in and increasing communication.

Using these ABCs as principles to guide your SDLC can go a long way to increasing its adoption and improving its effectiveness as well as allowing you to accomplish the next step in sequence F - Fantastic!

Product:  Obviously, you're the 'product' in this case and just like the decisions you make in a supermarket you want employers to see your 'product' in the best possible light.  These days it takes more than a resume to stand-out. Here are some quick and relatively easy ways for an IT professional to stand out in the crowd:

• Create a website:  Hosting services for websites range from free to less than $10/month.  I use yahoo which for $8.99/month gives me a WYSIWIG web publication tool, email addresses, blogs and FTP.  Use a domain name that is professional and easy to remember.  I use my own name (www.bryancampbell.com).  Avoid services that have 'nagware' or 'click-through' advertising (like www.bravenet.com, great for your cub scout site but not so good to land a six figure job).
• 'Add value' to your website by uploading examples of work you've done or papers/presentations you've delivered.  Use common sense and your judgement on any Intellectual Property issues.
• Keep the website focused on only professional items.  You can create sub-domains for your extensive matchbook collection but keep the focus of your website on its goal of finding you a job.
• Create multiple versions of your resume.  One size doesn't fit all and the same is true for resumes and jobs.  I have IT Management, Project Management and Agile experience.  I created resumes for each of these skills so I can better emphasize my experience for jobs that need them.
• Know what to emphasize:  People reading your resume are looking at hundreds of others.  They need to know education, certifications, years of experience and skills.  Give them what they need in big letters at the top of your resume and in the 'overview/goals' section of your resume.  Make sure you also have a lot of 'search' friendly references like product names, industry terms etc.  These are the terms that will get your resume picked out from Google and job board searches, recruiters will then want to see how much experience and education/certifications you have.
• Learn Word/HTML:  As you'll find out not everyone has the same version of Word and many job boards parse uploaded Word documents in very different (and frustrating) ways. 
• Save your resume in Word 97-03 format for the greatest reach. 
• Make sure you 'view' your resume in a variety of layouts not just 'Print' layout, use Web Layout and also make sure you print your resume to make sure it doesn't exceed print margins etc.
• If you're using a Mac be warned that about 0% of HR departments and recruiters use Macs, so make absolutely sure what you're sending can be opened in a Windows based Word machine. 
• Knowing some simple HTML skills will be very useful when uploading to the job boards, even <b></b> to emphasize job titles can help your resume stand out on a job board.
• When creating your resume make sure you have your name and contact information on every page in the footer or header.  You want it easy for someone to get a hold of you.
• Cross-link back to your website with examples of work or publications.

Market:  Once you have your product ready you need to increase the eyeballs that see it.  Obviously a website will quickly get you seeded into Google, Yahoo and Live but you'll want to turn to the big boards to get more specific views;

• Job Boards:  There are a lot of job boards available now but for an IT professional your best bets are Monster, Dice, Careerbuilder.  Unfortunately each is going to require you to create a customized resumes specific to their sites and they parsing tools each of them use for uploaded resumes work completely differently.  Careerbuilder is still in the 'stone-age' of requiring a text only resume but Monster and Dice let you upload HTML based resumes which you can format quite easily.  All of these boards have premium services which help you stand-out from the crowd.  I paid for a month-to-month subscription for all 3 of these services although I'm skeptical it helped much on the other hand for $10/month its not going to break the bank and you cancel at any time.  From my experience, theLadders was next to useless (and I even paid for a premium subscription), hardly any resume views and sixfigurejobs.com (which might be owned by the same company) was similarly ineffective although they might be better for sales/marketing types of jobs. 
• Business Networks:  There are a lot of IT specific business network sites but the best from my experience is www.LinkedIn.com.  Create an account and ask some colleagues to give you an endorsement which provides recruiters some immediate references.  Also, with your available time, scan the Q&A section of LinkedIn and answer questions.  This can not only extend your business network but if your answers are selected as "Best Answers" you get profiled on LinkedIn.  Other sites include www.plaxo.com and www.ittoolbox.com.
• Join User Groups and Special Interest Groups:  Take some time to explore websites that have communities of IT professionals and get active in their discussion forums.  It's a great way to stay connected and learn.
• Create a Blog:  Pretty well everyone has a blog these days and with some new-found time they can be a great way to demonstrate your skills/experience beyond what your resume shows.  Personally I keep my blog factual and emphasize more objective, empirical topics but you can also use it to sound off about your opinions on IT direction and trends.  Remember though your blog is a tool to help prospective employers better understand how you'll fit into their organization, keep a professional tone and make sure what you're publishing aligns with your job goals.

Sell:  Now you have a product and you've marketed it, you need to sell it.

• Create job agents:  All of the job boards have the ability to create a search agent for the type of job and location you're interested in.  Create a few of these and then build some message rules that will place these daily alerts into a directory in your email tool (otherwise you'll quickly fill your email up with these alerts).  Also leverage some of the 'meta' search agents like www.simplyhired.com which searches all the boards for a specific job attributes. 
• Apply/Apply/Apply:  Be aware that those 'perfect' jobs you're going to see on the job boards are never quite what they appear to be.  Most have been kicking around with different titles for months and quite a few get 're-branded' by recruiting agencies hoping to find a candidate that they can present to a company with a job opening.  However, if you don't apply you won't get interviewed, so leverage the 'one-click' services that most of the job boards have and submit your resume frequently just temper your expectations.  Think of this as your 'indirect sales channel', sort of like telesales.  Relatively low hit rate but cheap and easy to manage.
• Reach Out to Your Network:  Follow-up with your network letting them know you're available, you have a far better chance of finding a job through someone who knows you than via an emailed resume.  You'd be surprised where your next job can come from so cast a wide net and keep your email short and to the point.  Indicate you're in the process of a career transition and you're exploring opportunities, highlight your experience and skills and attach a copy of your resume. Don't expect anything and don't harass someone.
• Contact Headhunters/Recruiters:  Recruiters make their money by placing people with companies, however, you also need to give them some confidence that you can present well and deliver what their clients want.  The good news is that most of these recruiters have considerably more time that most employers to meet with you and learn about your background and experience.  Phone local recruiting companies in your area and ask to speak to a recruiter who specializes in your area and then see if you can meet them for coffee.  Remember its critical to make a good impression so come prepared, dress well and be professional, if they think you're someone they can make a placement fee from they'll be a lot more interested in promoting you.  www.Teksystems.com , www.Yoh.com are good national recruiting companies and there are local entities in every market that you can quickly google.  Be prepared though that these organizations are opportunistic and even if you've had a good coffee/lunch with a recruiter you can't sit back and wait, they're simply another channel to expand your reach.

So all of these tips will help you get your job search moving along, however, the final aspect is to monitor your progress and results.  Your first week should be spent creating your resume, website and joining job boards/networks.  From that point on you should spend at least two hours a day applying, emailing and posting blogs/forum messages.  By your third week you should start expecting to meet with people and you should be getting at least one or two resume views a day on the job boards and on your website.  At that point it's a bit like selling a house, if you get enough traffic eventually someone will make an offer.  If you don't get enough traffic you need to start fine tuning your product/marketing and selling techniques.

The final pieces of advice I would offer would be is leverage some of your new time to catch-up on activities/tasks you have around the house but more importantly spend some quality with your family and friends.  You might look back years from now and see that this was the longest vacation you've had so you might as well enjoy it!  And like all things remember "Trust your own instinct.  Your mistakes might as well be your own, instead of someone else's."

Note:  After two months I recently accepted a job with BMC Software Inc. after receiving four formal offers and countless emails, phone calls and coffees!

I recently wrote an article on ITToolbox.com about the use of Cards in agile oriented development projects.  In describing the use of task management cards I referenced the term "Wall of Wonder' which resulted in a number of emails asking for more information about this technique.  Essentially, a Wall of Wonder reflects some of Alistair Cockburn's writing about creating information radiators to convey project status that can be easily understood, changes frequently and is visibile to the team and other stakeholders (in XP parlance these are know as Big Visible Charts).  There are many ways to accomplish this from posting project burndown, defects, issues and stories to having green and red lava lamps that show the status of the latest CI build.  All of these techniques serve the purpose of lifting information about the project out of databases and proprietary tools like MS Project/Primavera/ReqPro/etc into the 'visual domain' where they act as a scoreboard to help project teams focus on the right outcomes.

A Wall of Wonder is a visual information radiator that software development teams use to manage their tasks and activities during an iteration.  The Wall of Wonder is a highly tactile and visible tool that requires very little in the way of infrastructure or training to implement.  The Wall of Wonder reflects activities and tasks associated with your iteration and to convey this, index cards are used.   One reason, index cards are so useful in managing complex software development processes is because they're so simple.  Index cards are readily available (I've personally driven to many Office Depots to grab cards prior to facilitating planning sessions at client sites), they require little in the way of training, they're highly tactile and they're inexpensive. 

One of the most telling benefits of the Wall of Wonder and leveraging Task Cards is the level of collaboration and engagement that occurs. The cards themselves are an invitation to 'have a conversation' about a feature or requirement, similar to that advocated by Ron Jefferies. Enough information is available on the cards to prioritize and assign work but not so much that a developer will know exactly how to realize the functionality on the card.  Another benefit of the cards is that different roles can work together to ensure that all the work on a card is completed.  On many of the projects that I have managed the final test of completeness was having a tester walk through the code with a developer to ensure it worked to its specifications and was appropriately documented.  The tester was armed with the Red Marker and when satisfied that a card was complete would 'approve' it with a mighty swipe of the marker.  Developers who claimed they had completed their task card but didn't have the 'official' red marker check were quickly reminded that they weren't really done.  The cards also became a fun way to show progress and bring some friendly competition into the development lifecycle.  One of the developers on a project I managed once completed five cards in a single day, from that point on he was nicknamed 'Five Card', a name that persisted for several years after the project!

If this topic sound interesting, I've written a more detailed overview of a real world example of a Wall of Wonder on my website.  I'd be interested in hearing more about how others are using Visual Radiators or Walls of Wonders on their projects, so if you have examples or ideas feel free to share them.

One reason, index cards are so useful in managing complex software development processes is because they're so simple.  Index cards are readily available (I've personally driven to many Office Depots to grab cards prior to facilitating planning sessions at client sites), they require little in the way of training, they're highly tactile and they're inexpensive. 

A frequent response to complex problems like software development is to find a comprehensive 'solution' to manage all of the myriad complexities that get introduced with writing software.  Features like a "database of requirements with an index of attributes", a detailed history of estimates, forecasts and actuals, versioning of every change made to a requirements by author and time... the list goes on.  Solutions like Requisite Pro, Doors and Caliber RM all come to mind.  All of these features have merit and there are legitimate times when a project might require some of them.  However, in most software development efforts the most important goal is creating working software.  Index cards become one of the most valuable tools for managing this process. 

This might sound heretical for a project manager but on many of my projects I didn't spend much time analyzing estimates and actuals.  At the end of an iteration I simply gathered all the completed cards, put an elastic band around them and they became another brick in the wall of our software development process.  If someone wanted to know what had been done from one iteration to another, I would weigh the two bricks in my hands and offer an assessment on whether velocity was increasing or not.  My focus was on enabling the teams and increasing their productivity.

Cards also have other uses.  A colleague of mine once said that at his software development company they used the the old cards from previous iterations and projects to wallpaper their meetings rooms.  I'd like to see someone do that with ReqPro!

Unfortunately, most teams get little direction or support beyond the idea of having a retrospective at the end of their iterations.  Generally, they start well but over several iterations attendance of product owners start to dwindle, many of the same problems get revisited every retrospective, the sessions either become rife with highly charged/emotional discussions or get bogged down in unactionable or questionable value problem areas ("We need more snack food in the room").

A big reason for these problems is that the teams don't receive any guidance or support in running their retrospectives.  Here are some tips on keeping your retrospectives working smoothly:

1. Establish a facilitator for your retrospective: This person should have experience and training in facilitation and understand how to maintain the right level of energy in a retrospective.  There is a wealth of information on effective facilitation techniques but a good book on the topic is Agile Retrospectives: Making Good Teams Great by Larsen/Darby and Schwaber.  You can review a Google Tech Talk presentation on YouTube.
2. Give your retrospectives 'themes':  After the initial excitement of the first few iterations most teams can benefit from having a focus area for their retrospective.  Topics like "How Can We Improve Our Teamwork" or "How Can We Increase Code Quality" help focus discussions and can break out of the 'We've discussed this before" syndrome that can accompany retrospectives.
3. Get participants engaged:  One key to re-energize your retrospectives is to get participants moving and participating.  Have team members write sticky notes with improvement suggestions and put them on whiteboards.  Have the team spend time moving the stickies into categories.  Use the Fist of Five to facilitate voting on these techniques.
4. Change things up:  If your retrospectives are losing their energy and benefits, try moving them to a different location.  Holding one outside on a nice day or have a Build a Sundae theme with some ice-cream and condiments can re-establish interest levels.

These are only a starting point for re-energizing your retrospective and there are lots of good blogs like David McLean's which offer advice and suggestions. I'd be interested in hearing how others are managing their retrospectives too.

For the last 20 years my career has involved software development (in fact if I include all of the software development I completed on my Apple II e/c in High School you could say I have close to 25 years of software development experience!).  The last 8 years has been focused on iterative development techniques and what is now widely described as Agile.  I came to my understanding of software development and IT in general steeped in a tradition of large process frameworks from the PMI/SEI and RUP.  I leanred and applied the Zachman Framework in my early Enterprise Architecture efforts and eagerly absorbed the V-Model as a mechanism to manage projects and their complexities.  As a project manager, these tools and techniques were invaluable in understanding how to manage the myriad of complex parts that comprise a large project.  My early experiences in project management involved introducing time-boxed, iterations and techniques like Domain Modeling and System Sequence Diagrams. 

In 2001 I had an opportunity to apply XP to a project and became familiar with terms like YAGNI - Ya Ain't Gonna Need It, Design Patterns, Unit Testing and paired programming.  Later I leveraged story cards to manage tasks and established Information Radiators to provide visibility, I saw the benefits of Test Driven Development and Continuous Integration.  I read about Scrum and leveraged Daily Stand-ups, introduced burn-down charts and began to leverage retrospectives with my projects.  About three years ago I started introducing Executable Requirements (Fit/Fitnesse) into projects and Feature Driven development,  All of these techniques were valuable and over the years I've been able to refine most of them through practical experience.

However, I applied all of these techniques within the context of a larger project management framework.  Classic PMP components like budget management, communication, and resourcing needed to come from somewhere,  Deployments required coordination with other projects and release windows.  Government standards like HIPPA or SOX had to be addressed while also ensuring that integration testing was coordinated with other systems and sometimes other organizations.  I learned early on that not receiving early involvement from Enterprise Architecture teams and Network Operations could delay a project more than not getting well defined requirements.  The Unified Process helped me manage risk across project phases and structure work across disciplines with roles and responsibilities.  The agile techniques I mentioned above seamlessly integrated into these broader models and the results were tangible.

This is the new face of Agile as I see it, an agile that embraces the value system of the Agile community but within the context and realities of getting something done in large enterprise organizations.  In the least few years though, I've come across a number of agile experts (or agilistas) who have 8 to 10 years of experience in agile techniques but little awareness (even at the broadest levels) of discplines outside of Design and Implementation.  I'm frequently surprised at the level of dogma that surrounds their interpretation of Agile and the lack of tolerance for anything outside of the realm of Design and Implementation.  Most have little appreciation for different roles on a project let alone artifacts or awareness of different stakeholder needs.  Increasingly agile is becoming a marketing term and it's being leveraged to justify poor work habits and an exclusively developer centric perspective on building software. 

I'm not alone in these observations and I've noticed others starting to write aobut Post-Agilism like Jonathan Kohl and Jason Gorman.  Philippe Krutchen recently wrote a very interesting piece called Voyage in the Agile Memeplex which discusses agile as a culture and the effects this has on software development and effective communication.

It's time to once again start looking at software development as an engineering discipline, one that requires a balanced perspective which leverages the experience of the past with the new ideas of the future.  Post-Agilism is already underway and it's time for the industry to begin adopting these ideas.

There are two dimensions of EssUP that look interesting.  The first is Jacobson's recognition that while people buy a lot of his books, most don't actually read them, so consequently he's based the methodology on playing cards that are easier to read and presumably follow. I think this is an important recognition in actually having a process 'used' by people and it seems like an idea that OpenUP and other broader methodologies should consider.  The other dimension is the focus on 'practices'.  RUP/OpenUP/EUP all have tightly coupled workflows/artifacts/roles and sprinked throughout are practice ideas like 'iterative development', 'component design', 'test driven development' etc.  It's these practices that actually make most methodologies effective and Jacobsen has identified these as the building blocks for EssUP. 

I'd be interested in hearing more from anyone that has used/explored EssUP in more detail.

One of things that I personally think is important is ensuring a safe and productive workplace for people in order to maximize their potential.  Part of this comes from ensuring a safe work environment and instituting a culture of tolerance and respect, however, another dimension that I think is also important is ensuring that the workplace is also 'fun'.  If you can have fun in your workplace my logical extension is that you must feel safe since its hard to have fun when you're feeling threatened or worried.  When I was the VP of Delivery Services at Valtech I ensured that each one of our Development Centers had some kind of 'activity center', Wii's and Guitar Hero, Ping Pong tables and electronic dartboards were all available for tournaments and just casual play.  We even had an official World of Warcraft guild for employees and spouses (and there were a lot of spouses!).  When I was at BMC one of the events I organized for my staff was a rather remarkable scavenger hunt/trivia pursuit/cranium game that was provisioned by a company called The Go Game.  It was probably the best team building event that I've ever been involved in and the company was creative enough to customize the game so that our India team could participate as well.  Of course, I come by this honestly having spent my early years running a small company that provided Doom network gaming tournaments.

By adding some 'fun' to the workplace it's opened up new communication channels amongst staff and it's allowed people to connect in ways beyond their work commitments.  It's a tricky area of course, one person's 'fun' is not always anothers.  When I took over at Valtech the only organizational fun was playing poker, however, not everyone enjoyed playing and felt excluded and even resentful that this was the only way to interact with their colleagues outside of work.

However, it seems that you can take the whole of idea of fun in the workplace to a whole new level.  I read an interesting article in the Utne Reader about the "infantilization of corporate America" which describes companies pushing the boundaries of this idea of fun to the point that employees feel like children in school.  Clearly there are some 'dos and don'ts' when pursuing these ideas!

Initially, I was skeptical about a social-networking tool like this as it emphasized activities not outcomes.  However, upon reflection and reading an interesting article from on my old alumni-BMC blog, I now think this would be a very powerful tool particularly for geographically dispersed teams. Although Twitter emphasizes activities, its these activities that connect people in a community and a software development team represents a focused community.  Having a tool that allows team members to understand the activities that others are engaged in provides visibility that can only be accomplished when working in the same general area.  In larger companies and in globally distributed projects it's not practical/possible to have teams working together.  Twitter and some of the other micro-blogging services like Pownce (which allows you to blast out links to events and even files... which would be useful when a document had been updated) fill a void that other tools like Wikis (Atlassian Confluence), Version Control solutions (Subversion), IM solutions (Jabber), Communication tools (Skype) and Application Lifecycle products (Rally) don't address.  At some point all of this seems likely to converge but until then it will be necessary to stitch together these solutions to really ensure effective collaboration of your teams.

If you're using any of these Web 2.0 tools in your environment I'd be interested in hearing about their benefits and what effective practices you've discovered.