I, on the other hand, had plenty of questions. Just as a few examples, I was very interested in finding out more about what this company does, what type of environment they have, and specifically what they were looking for in a candidate (aside from the obvious requirements listed in the job description).

What is the value in asking all of those questions? The obvious benefit, of course, is that the more information I have, the better I am able to make intelligent choices as to whom I should submit for the position. That way I don’t waste our client’s time or the candidates’. But the more subtle value is that the hiring manager experienced my interest in their company and their needs, and observed my interest in helping them solve some of their problems.

How do you come across in your interviews? As someone simply listening to what the company has to offer, or as someone who is truly interested in what the company does, what the company needs, and considering how you might be able to help the company meet some of those needs? The only catch in all of this is that your interest has to be genuine. All else being equal, it’s a slam dunk which candidate is going to get the offer.

1. Put the word “Resume” on your resume. Perhaps obvious, but probably the most overlooked. Most recruiters I know begin their keyword search with “resume,” and then a string of keywords related to the job description. Yes, in the past this has been considered bad resume etiquette, but something like “Resume of (your name)” will be perfectly acceptable.
2. Make sure your most important keywords are embedded in a descriptive sentence. As an example, if you want to highlight your Visual C++ experience, make it part of a sentence such as, “Lead programmer on system interface solution using Visual C++.” The reason for this is that some companies will use keyword scanning software which will distinguish between keywords found in a keyword list (such as a skills matrix) and those found in a descriptive sentence. Keywords found within a descriptive sentence are weighted higher than those that aren’t.
3. Spell out your keywords in all of their common spellings. Visual C++ should be listed on your resume as “Visual C++” as well as “VC++” and “MSVC”.

Again, these are just a few tips to get you started, but an Internet search on “resume keywords” will bring up a wealth of information on effective use of keywords to maximize the chances of getting your resume noticed.

Our content ranges from broad industry topics to very focused technical articles. We have a long established practice of giving industry professionals a chance to speak to a large audience through our publications and I will continue that effort.

So, I am seeking writers:

Are you an intelligent professional that can provide valuable material for our readers?

Our articles are not always strictly about technology. If you’re versed in a subject, such as marketing as it relates to our industry, we’re listening.

For reference, our newsletters can be viewed at http://www.stoutsystems.com/newsletters/. We publish a four-page printed newsletter at the start of each quarter and an email newsletter during the other eight months of the year.

The easiest way to get in touch with me regarding this is to visit http://www.stoutsystems.com/participate/. This page answers some of the most common questions about contributing to our publications and has a form at the bottom where you can drop me a line.

I look forward to working with you!

• No profile picture

• No job history

• No education listed

• No groups joined

• No recommendations

• No interests listed

• Few or no connections

The absence of one or two of these is hardly a show stopper, but when most or all of them are absent, it really makes me wonder why the person created a LinkedIn profile. Which then makes me wonder even further about the candidate. Fair? Probably not, but that’s all too often how HR people and hiring managers think.

So, if you do take the trouble to create a LinkedIn profile and intend to use it to help you in seeking that next opportunity, make sure to maximize the positive impression you make on a potential hiring manager by ensuring that your profile works in your favor. Take the few minutes to beef up the content and help visitors to your profile really see you at your best.

Agile Acceptance

by Matt Wickey

By now, it’s pretty much confirmed that, in the world of software development, Agile processes are here to stay. At their best these process offer shorter development times, higher quality, and a generally happier bunch of programmers. In fact, you cannot review industry want ads without seeing the word “Agile” sprinkled liberally all over the place. Yup, Agile is here to stay.

Why, then, do we not find all corporate IT departments converting to cube-less, team-centered Scrum factories at breakneck speed? For the record I have actually visited such a place and, I must say, it is pretty cool. But they had a unique set of circumstances (which I’ll discuss in a bit) that made the global adoption of Agile more attainable.

But, to the original question: with all its highly touted success, why isn’t conversion to Agile an easier sell?

One reason: MANAGEMENT!

Managers are often risk averse and cost conscious. Aversion to risk means they probably don’t get warm and fuzzy over development methodologies that are light on hard delivery dates. Remember, for better or worse, most managers are accustomed to IT project plans that GUARANTEE delivery by a date certain. Just because those dates are almost never met doesn’t mean managers blame the process—they blame IT who can’t deliver on time! Try telling them that these same IT “pros” can improve things with some new methodology that doesn’t require delivery dates but will make them happier really soon…

Yeah, right.

And their cost consciousness means the idea of tearing down perfectly good cubes and replacing them with chaotic wide open team areas where messy developers run the show… well, it gives them the willies. And, if you think they balk at that, try telling them they now need two programmers (for paired programming) where they used to have one. Somewhere a Lean management consultant is having a mild coronary at the mere thought.

Remember the company I mentioned before that successfully implemented Agile? What was it about them that made their efforts a success?

1. When they started with Agile they had a history of significantly late (often non) delivery of IT projects. Given that, company management was ready to try something, almost ANYTHING, new.
2. They had a CIO that believed in Agile processes and demanded to convert to them en masse, rather that piecemeal. This meant their Agile experience was more culture shift and less experiment.
3. They brought in expert consultants who understood how to implement Agile and made sure their first project was a smashing success—orders of magnitude faster and much higher quality.

If you read between the lines you’ll see all the above points indicate management involvement. In fact, without the dedication of the CIO, it’s likely this conversion would not have worked. This same company had attempted Agile “projects” before without success. To really do this required a change in culture (ex. developers NOT getting pulled off projects to do production support) that couldn’t be attained one project at a time. And that kind of change could not have happened without high level management support.

I know. This sounds like another anti-management diatribe for which we programmers are famous. But it’s not. Let me be clear—management is not the problem! But they are the target audience. It is up to those of us who believe in Agile to make a compelling, coherent case FOR Agile.

And that case is this: Agile processes, when applied correctly to the right problems, can do what management wants most—reduce risk and cost.

If we make that case with plenty of documentary evidence, the solution will sell itself.

As the resumes come pouring in, recruiters and hiring managers narrow down the list by looking through them for the tell-tale signs that this candidate might have the experience called for in that particular position description. Depending on the job description and the resume, this might be an easy task, or it might be more difficult than finding a needle in a haystack.

Keep in mind that recruiters and hiring managers are often poring over dozens and dozens of resumes for a posted position. If it’s taking too long to tell from a particular resume whether or not a candidate has those qualifications, guess what probably happens to that resume? Unfortunate for that candidate, but a golden opportunity for you—if you take the time to include in your e-mail some bullet points that speak specifically to that job description.

In our example above, it would go something like this:

“I am responding to your job posting for an eCommerce Web Developer. Specific to this position,

• “I have been developing eCommerce Websites for over four years.
• “I would consider myself expert in JavaScript, JSP, and CSS.
• “I have had considerable experience building AJAX interfaces.”

And you would continue, touching on any of the requirements that were an actual match to your skills and experiences. I guarantee that if you do this one thing, you will truly maximize the chances of your resume being escalated up to the next level of consideration.

Our own Bill Heitzeg and John Stout attended such a workshop at CodeMash earlier this year and developed a good relationship with Mary and Tom. It was this relationship that opened the door for the session.

With limited seating available Stout hosted a sold-out crowd of 50 business and software professionals who were treated to an in-depth discussion of lean computing concepts.

There was also a detailed exercise demonstrating the power of value-stream mapping in identifying organizational and process waste. It is the elimination of such waste that defines lean processes of all kinds.

Mary and Tom were good enough to stop in between engagements and conduct the workshop. All proceeds from ticket sales went to benefit the Ann Arbor Chapter of the Association for Women in Computing and their scholarship fund.

You can find more information about Mary and Tom’s work and travels at their website www.poppendieck.com.

Three-time author, speaker and trainer, Mary Poppendieck has a long, notable career helping companies produce great software. After retiring from 3M in 1998, Ms. Poppendieck started helping software companies around the world adopt the “Lean Patterns” that have been so successfully applied in manufacturing. In 2003, she published her first of three books: Lean Software: An Agile Toolkit. Focusing on the process of developing software, not necessarily on the software code, Ms. Poppendieck gives teams the tools and techniques to analyze, understand and continuously improve delivery. In her third book Leading Lean Software Development (2010), she teaches decision-makers how to continuously improve the ability of their organizations to consistently produce great software.

“We were extremely pleased to be able to have such a distinguished speaker in Ann Arbor,” said John W. Stout, founder of software industry consulting firm Stout Systems. “Mary’s seminar is unique and demonstrates effective techniques for removing waste thereby reducing cost from the software development process. The feedback from the participants was uniformly positive.”

The event was sponsored by Stout Systems in conjunction with the Ann Arbor Chapter of the Association for Women in Computing (AWC-AA). All proceeds from the event went to benefit AWC-AA’s college scholarship program.

“We are thrilled that Mary was able to stop in Ann Arbor for our April program,” said Lisa Luczek, President of AWC-AA. “The program was sold out, and enabled us to raise $500 for our scholarship. It was an opportunity for almost 50 IT professionals to learn about lean software development and have their processes critiqued by Mary. It is an excellent example of the kind of community and professional development that AWC-AA works to create in the IT space.”

About Stout Systems
Stout Systems is a software development and staffing company that is fueled by the most powerful technology available—Human Intelligence. Stout eliminates the stress, frustration and overwork all too typical to software projects. Stout helps say goodbye to frustration and hello to achieving project targets and technical staffing requirements. Founded in 1993, Stout has offices in Ann Arbor and Detroit, and a national client base. To learn more please visit www.stoutsystems.com.

About The Ann Arbor Chapter of the Association for Women in Computing
The Ann Arbor Chapter of the Association for Women in Computing (AWC-AA) is part of a national organization. AWC was founded by fifteen women in Washington, D.C. in 1978, and it is one of the first professional organizations for women in computing. The initial purpose of the group was to establish and encourage communication among women in computing. The scope of the organization has grown to include professional networking, employment assistance, continuing education, and mentoring. To learn more please visit www.awc-aa.org.

What is Failure Demand?

by Bill Heitzeg

All companies that use or support software of any kind will, at times, see that software fails. The demand on your company’s resources to handle this failure is sometimes called failure demand.

For example, when a customer has a problem using your software and they call you to solve it, that’s failure demand. If it turns out that the phone call results in your support person discovering your software has a bug, the time to discover that bug, by both you and, if you’re being fair, your customer, is failure demand.

When your developers have to stop everything they are doing to fix the bug, that’s failure demand. And of course the time to redeploy the patch and the communications associated with this patch are all failure demand. Rigorously looking for, exposing, discussing, tracking and eliminating failure demand can have an extremely positive effect on any IT organization.

Mary Poppendieck writes extensively about this in her articles and books, giving excellent guidance to organizations that are looking to attack this problem. In her latest book, Leading Lean Software Development, Mary describes failure demand as waste: “Waste is anything that depletes resources of time, effort, space, or money without adding customer value.”

To learn more, pick up one of the Mary’s books, spend some time at Poppendieck.com or find out about our upcoming “Mary Poppendieck comes to Ann Arbor” event.

Recently, Peg Bogema and I gave a presentation to the Ann Arbor Association of Women in Computing. The topic: Insider Tips on Resume Writing, Interviewing and More. The bad news is that we told attendees that our presentation would only last an hour at most. The good news is that most everyone was still there, taking notes, after more than 2 hours of stimulating discussion.

Feedback from the presentation has been very good, and we’ve had the opportunity to help several candidates implement some of the resume ideas that were discussed. Because of the positive response, we will likely be repeating this event. Stay tuned for where and when!