Read the Original Article at http://www.informationweek.com/news/showArticle.jhtml?articleID=240147660
The demand for agile developers far outweighs the supply. And by far, I mean by light years. Take a look at this infographic that shows how wide the gap is between the available pool of agile developers and the number of job openings for agile. This "agile gap" has significant implications for developers and hiring managers alike.
The first implication is this: Most shops looking for agile developers aren't yet agile. They're either just starting out with agile, or they want to be agile, or they say they're agile but really aren't. Odds are high that the shop you're interviewing with for that agile position could be a potential nightmare gig in the making.
If you're a committed agile developer and you're interviewing for a new gig, how can you figure out if the company you are interviewing with is full of hot air or really is an agile shop? You don't want to discover your new team is just starting out with agile unless you wanted to help build such a team in the first place.
The truth is that there's no such thing as a perfect agile shop, because the industry is decades away from full maturity. There are companies that understand adoption of agile development requires a complete change in culture, and they've made or are making the transition. But there remain far more companies that don't have a clue about the culture of agile.
[ Looking for a promotion? Check out our Secret CIO's advice on moving up the career ladder -- 5 Steps To That CIO Title. ]
For agile developers, it's crucial to understand where a prospective employer is on the agile maturity curve before signing on the dotted line:
If they are agile, it will probably be a good fit.
If they aren't agile yet but realize they need to change, and are willing to commit to change, then it might also be a good fit -- assuming you're interested in taking on the role of change agent. Not an easy job, to be sure, but some people (like me) thrive on these challenges. If that's you, the position is worth considering.
If they aren't agile and think they can get there by hiring agile developers without really understanding the cultural change required, that's a recipe for disaster. Run for the exit.
How can you know where a potential employer falls on the agile continuum? Here are 10 questions designed to get at an organization's culture, because culture makes all the difference between organizations that succeed with agile and those that just talk a good game.
This is the number one question that needs to be answered, though it may not be a question you ask out loud. Use your eyes. The physical work environment can be an indicator of the culture. Do they work in an open space? Do they work in cubicles? You can still have an open work culture in a cubicle, but it does mean that the space is working against openness and, perhaps, that the company doesn't value openness enough to build it into its work environment.
2. How do you structure your work teams?
Next, I would ask about how people are organized. Will you work in a cross-functional team or are you going to be working in a silo? You're really looking for a collaborative, open, team-based work culture. Siloed teams by definition cannot be agile.
3. What tools and languages do you use?
While agile isn't associated with any particular language or toolset, these can give an indication of the culture. A tool doesn't make or break a collaborative culture, but a tool designed for a top-down development process is not well-suited for an agile environment. According to our research, the most popular language platforms in shops that self-describe as agile are Java and .Net (this usually means C#).
4. How much customer contact will I have?
Ongoing and iterative customer feedback, whether for internal or external customers, is essential in the agile process. How does this company or department engage with its customers or users? Does the company or department just go out and gather requirements? Or do they have collaborative sessions with the customer or user? That's really what agile techniques are all about. If the prospective employer asks you how you would use a set of requirements to create a solution, you know they're not doing agile!
5. Will I speak with my potential coworkers during my interview?
If you are interviewing with a company that shields you from the people you will be working with -- e.g., if you're just talking to managers and HR people -- it's possible they haven't discovered the value of building a team-centered work environment. When I was VP of development at Primavera, we conducted group interviews. If we knew someone would be working with three other people on a team, we'd have those three people interview the candidate. Sometimes we'd actually give them a problem to solve together, because we wanted to see how they interacted as a team.
6. How pervasive is your embrace of agile?
Just the other day I was talking to an agile developer about his recent experience interviewing at one of the largest financial institutions in the world. This company is a great employer, but it's also a very old company. It has a lot of old systems and tangled processes. He was interviewing with a smaller group that successfully embraced agile practices, but the organization as a whole might not be interested in agile development at all. Such an environment could limit your career path within the organization. Conversely, joining an innovative agile team that's making waves in the global IT environment could mean you're well positioned as a pioneer who's helping bring agile to the company as a whole. You need to assess the organization's agile embrace, and determine what influence it will have on your career path, and how it aligns to your career goals.
7. What problems have you encountered in adopting agile?
Everybody in manufacturing falls in love with Toyota's production system. People are always trying to mimic how Toyota does things. And there's no shortage of technologists who talk about how Toyota's system can apply to the IT supply chain. But if you talk to people who work at Toyota, they don't think of what they do as a "system." It's just what they do. No one thinks about the culture. They just live it. To that end, ask for a back story on the organization's agile adoption. If they can give you a detailed account of their problems adopting agile processes, then they probably aren't very far along. Teams that are far along are living and breathing the method, and it's no longer a struggle.
8. Have any of your people spoken at conferences or published about your use of agile?
When you're researching a potential employer, try to determine whether any of their people speak at agile conferences, publish books or articles, produce an agile blog, moderate agile communities online, and so on. If there are agile thought leaders on staff, that's a very strong indicator that their use of agile is mature.
9. Are your people certified and trained on agile? Do you offer training and certification?
A lot of employers require certification for the people they hire. You can easily turn that question around and find out if the people already on staff have been certified. Training helps people understand the culture of agility versus the methodology of agility. There's quite a leap between the two. You can learn the agile methodology in an afternoon by reading a book. But it's the culture of agility that makes the difference between a team that wants to become agile and one that already is.
10. What are your metrics for post-release defects and customer satisfaction?
The absolute numbers don't really matter here. What you're looking for is whether they've established a culture of metrics and continuous improvement. People only measure what's important to them. Any metrics that the potential employer can share indicates what they focus on, whether they have a quality mindset and whether they are customer-focused. I say the numbers don't matter because if, say, the company tells you that its customer satisfaction is only 70%, but there is a target in place to get to 85% in the next year; if there's an initiative to engage with customers; if they're getting the Scrum teams lined up and talking to the customers ... then you're hearing the words of a quality mindset, a customer focus and an agile approach. Even if their metrics aren't the greatest, the fact that they have the metrics is a great sign, because you, as an agile developer, would be coming on to help them improve those metrics no matter what they are.
Your Turn: What Do You Want?
This is the most important question, and one that obviously you must ask yourself, not the potential employer. As an agile developer looking for a new job, are you looking to go into an established, finely tuned agile environment? Are you OK joining a team that isn't truly agile yet but is fully committed to becoming so? Are you looking to help create an agile environment in an organization that's just getting started? Are you comfortable being part of an agile team in an otherwise non-agile organization?
It might not be a bad thing to come into a messed-up shop if, when the company leaders explain why they're looking for agile developers, it's because they know they're messed up and need help to make the change. The self-awareness of the organization is crucial, as is your personal self-awareness about your needs, capabilities and desires.
Some people like a challenge. Give them an organization that's totally messed up, and they find it fun to turn it around. But you have to be in the right circumstances. You need the power to make changes and the support systems to help make them happen. If you're going into a troubled organization as a developer tester, you won't really be in a position to make the changes happen. In that case, make sure that the company is committed to making the cultural change needed to become agile. Talking the talk in the job description isn't enough.