In a previous blog post, I ranted a bit about how candidates can make themselves more attractive to employers. While I still am interested in things from a employer's perspective, there are three critical consideration for a candidate: Do I want to do the role offered? Is there an opportunity to have an impact? Will I have the support and environment necessary to effectively do the job?

For each candidate, the consideration of each question will vary as well as its important. During all research and interaction with the organization, a candidate should structure her questions to build a "dossier" that addressees these concerns.

Do I want the role offered?

While a relatively simple question, it requires that a candidate has a clear sense of his goals and priorities. Timing is generally a key component, as different roles may be more or less crucial throughout the different stages of professional development.

Is there an opportunity to have an impact?

Ultimately, I think the most rewarding positions are ones in which there is an opportunity to have a significant impact to the organization. The organization benefits and the candidate usually does as well; the experience is generally better and prospective employers want to know what results were achieved. The scope and scale of this opportunity will usually vary with the position; a developer who introduces TDD to a group may help lower defect rates while a VP of Engineering has the opportunity to impact the company's profitability. However, I think all candidates, regardless of the position, should be ambitious and consider the largest impact the role may have. Similarly, it is a big warning sign if the position being considered has little impact to the organization; there will generally be few resources, support, professional development, etc.

Will I have the support and environment necessary to effectively do the job?

This is a very open ended question and probably the most personal for a candidate. Part of the consideration is about organization support: autonomy, authority, budget, latitude, and counsel are some significant elements. Environment is quite personal. Some candidates like dynamic, fast paced environments and others prefer academic settings. For some people, co-workers that can be potential friends is significant. Some people need flexible working hours. Ultimately, an employee will be most effective in the environment best suited for her.

While these questions may seem obvious, I am always surprised by how few candidates (or so it appears) are trying to address these considerations. A key part of my evaluation of a candidate is an assessment of his evaluation of the position; I want candidates who are looking just as hard at my organization and I am looking at them. Also, you will notice that there is a certain bias in these considerations towards professional development and satisfaction. I've made no mention of practical considerations such as salary. While practical concerns need to be satisfied, I don't think they should be prime motivators. This is not to say that elements such as salary aren't important considerations, but I think it is harder to find the position and organization that matches well with the three described concerns than to find a position to satisfy practical issues.

Brian Marick recently posted a blog entry noting the importance of marketing agile development to executive management. As stakeholders, management stands to gain the most from agile development.

The timing of Brian's post is somewhat coincidental, as this topic has been on the forefront of my mind. I think the next phase of generating agile adoption is to bring the campaign to management. It bothers me that I see mostly developers and technical professionals at conferences and very, very few members of management, particularly senior management.

I've been discussing this topic with people much smarter than I, in particular my wife. She has an MBA and works in marketing. Based on my discussions with her, the following are some ideas for raising the visibility and adoption of agile development methods to senior management.

Audience

Executive and senior management, particularly CIO's and CTO's, should be the demographic of this marketing effort. This poses some challenges, as such managers are generally removed from the actual development efforts and don't have much first-hand knowledge of the problems with traditional, heavy-weight methods. Making matters worse, middle management frequently withholds details about complications and, at times, reports a more successful depiction of projects than reality. Middle managers (those in the trenches) are the real "customers" of an agile process, but they are invisible; they have low public visibility and are a needle-in-a-haystack for a marketing plan.

Part of the challenge will be educating senior managers, while "saving face" for the middle managers, as we ultimately need their support.

Brand

Brand, brand, brand. It is the key to marketing. A brand defines the expectations of the vendor / product for the customer. It is the reason you choose product A over product B. For example, Nike caters to the "hard-core" athlete, be it recreational or professional. Volkswagen is about the "serious driver". Such strong psychological and emotional elements are quite common in consumer brands, but they can have a place in business brands as well.

This is the first action item for the Agile Alliance: define the brand of agile development. More precisely, what is agile development? The answer must be succinct and precise. It may vary for different audiences, but the core message must be the same.

This is a major challenge for the agile community. There is much debate over the question of "what defines agile?" and "which methods qualify as agile?". The goals and ideas of the Agile Manifesto, Agile Alliance and agile community have developed and are continually being revised.

But in order to have a brand, we must appear to speak with one voice, with one consistent overriding point of view. A brand defines the product. Consider the situation in which a business is choosing among multiple vendors. An organization will not trust a vendor whose message waivers and doesn't appear to have its act together.

Furthermore, the agile brand needs to be about more than ROI or business value. How would this be different than the claims of any other methodology, particularly the high ceremony, traditional processes? The ways in which agile development is different are important, but so are the commonalities of agile development and any other sound business theory or practice. (We can't have claimed to re-invent the wheel; business types will assume they know business better than we do.)

This doesn't mean there must be one agile methodology. The Agile Alliance can be the "parent company" that has multiple product offerings, each appropriate to a different context. But the overall message must be clear and consistent. We must determine the 30-second elevator conversation that answers the question "Who is the Agile Alliance and what is Agile Development?"

Getting Started

Many people don't know the Agile Alliance even exists. Its important that people associate agile development with the Agile Alliance.

I think the trade shows, conferences and journals that cater to CIO's/CTO's are a good start. I don't know what efforts have already been directed toward this, particularly sponsored by the Agile Alliance.

I know there was an executive track at ADC this summer. I don't know how successful it was. I think tutorials, seminars and workshops targeted to executives are a good idea. I think the agile community should invite any contacts they have in executive management.

I also think we should "recruit" the help of those in the business world. For example, Rob Austin is a Harvard Business School professor who has a strong interest in agile development and his research is about software development. I believe many in the agile community have a good relationship with him (among others). These individuals can be valuable resources.

Information Resources

Assuming we get the attention of executive management, we need to be prepared to provide information that is relevant to them and directly addresses their concerns.

There needs to be a catalog of agile practices and some guidelines regarding their approach. The roadmap section of the Agile Alliance website needs to be flushed out. (I happen to have a particular interest in the is topic, as does Steve Berczuk.)

Executives will want metrics that quantify ROI of agile development over other methods, adoption rates, success rates, etc. Information from the Standish Group's Chaos report would probably be useful.

Challenges

The Agile Alliance is a non-profit group that doesn't control or directly sell agile methods. Therefore, the requirements are similar to those for the consortium that markets milk.

I would expect an executive to request referrals from the Agile Alliance and she would expect the referred consultant (or firm) to deliver an "official" agile development process. Once you build the brand, it is important to maintain that relationship and protect the trust and expectations of the market.

This raises some concerns. How should the Agile Alliance provide endorsements? (I think some form of a referral service will be necessary). Questions about certification are a natural progression, which opens a huge debate. For example, a few months ago many in the agile community (including myself) went on the record to oppose SWEBOK. Will we eventually need to form our own version of SWEBOK?

This is somewhat a moot point. There are many strong forces already trying to standardize the industry. It might be negligent of the Agile Alliance to not cast its hat in the ring. This also becomes more important as agile development goes mainstream; most existing practitioners of agile development understand the principles of agile and faithfully practice it. I fear many mainstream adopters will claim to be agile and not understand it.

The challenge for the Agile Alliance is to remain "agile" and not bureaucratic, while maintaining some degree of conformity and unity. Brand integrity is necessary for successful marketing.

These are just some ideas. I think some attempts have already been made to market agile development to executive management. I think devising a marketing strategy raises many issues that the agile community must face and make decisions about. This will challenge us, as formal organization general complicates a good idea.

So I have finally done it. I have started my very own blog. I have been intending to keep a journal for some time now. It was just one of those things that I hadn't got around to doing. Andy Tinkham convinced me it was about time, though it didn't take much convincing.

So why did I want to keep a journal anyway? There are a few reasons, though I mostly want to capture my musings, ramblings, and thoughts. I hope that the act of writing will force me to focus my thoughts and develop a coherent voice. I need to learn to be a little more stingy with words; I tend to be a bit verbose.

On the practical side, I am a software developer and coach who has a lot of ideas about development processes, team dynamics and the various technologies we use. I hope to capture and refine these thoughts. Also, I frequently make references to books, sites, and tools to others that I work with. I would like to provide a listing of for these references and reviews. I also work on a variety of open source projects (like NUnit) and would like to discuss them.

I also love to cook and watch movies. You will probably find a lot of ramblings about both.

Finally, if by some miracle someone else reads this, I hope to get feedback from people regarding my ideas and their related experiences.

What can you Expect to Find Here?

• thoughts on software development
• reviews of books, tools, technologies, movies and restaurants
• conference and workshop reflections
• open source projects
• article drafts
• recipes
• random thoughts