The reality is that an agile transformation radically impacts essentially the entire range of functions within IT, and even impacts many functions outside of IT that interact with IT. This is why an agile transformation must be approach as a major organization change effort, and not simply a "project coaching" effort.
Business StakeholdersBusiness stakeholders include people or groups such as project sponsors, users of the software application, and system owners. Agile requires that business stakeholders refrain from performing an in depth requirements analysis before a project begins. Doing so will severely cripple an agile project, which relies on continuing interaction with the business stakeholders throughout software development. If requirements have been done up front, the business stakeholders will feel that they have already invested substantial time, and will not want to do so again during software development. In addition, the software development team will have the task of translating the up front requirements into agile "stories", and this translation is both time consuming and difficult, and inevitably results in reexamining each requirement in detail. It is rare that requirements do not substantially change during such a rewrite - and so the effort to write requirements down in detail up front was wasted.
Contracts and ProcurementFor organizations that contract out their software development work, agile changes everything. The traditional approach of locking in a fixed set of features, cost, and timeline is completely antithetical to the way that the agile process works. Trying to fit an agile project into such a framework will severely hamper the project and put it at risk. Agile relies on the ability of the business stakeholders to make decisions throughout the project in a fluid manner, and such fluid decisionmaking is not possible with a fixed price fixed duration, fixed feature set contract.
Fixed feature contracts also set the parties to the contract as opposing interests. Agile relies deeply on collaboration and trust, and a climate of opposition will undermine an agile project. Agile teams need to be able to speak frankly with their customer, saying things like, "We have had difficulty implementing feature A, because your data center has not provided an environment in which we can test it, but we will be ok if we can move the feature to the next release." In an agile environment, this type of discussion is a friendly one, and takes place while discussing all of the other project issues: a decision is made and everyone moves on. In contrast, when there is a fixed price, fixed duration, fixed feature set contract, failures to provide anything by either party can often escalate to a contract level, with each side arguing for cost or price changes. Since agile development is very fluid, such issues occur frequently, and so a rigid contract structure will result in a great deal of dispute, on an almost ongoing basis. What is needed instead is a contract that lays out goals rather than specific deliverables, and that provides the customer with a way to either renew or not renew the provider if things are not working out.
Portfolio ManagementMost organizations manage their IT project portfolio by reviewing the ROI for each project and deciding whether to renew or cancel. This approach does not work well for agile projects because agile projects are best constituted as ongoing investment areas rather than discrete projects. Further, agile projects require more active oversight than traditional projects, because agile projects generally are not part of a "master schedule" that identifies the interdependencies across all projects. For agile projects, there is no top level project plan: there is a high level backlog of work items. It is imperative to identify cross project dependencies and manage those proactively either at a program level or at a portfolio level, or both.
Project and portfolio metrics also radically change for agile projects: instead of measuring on-time, on-budget for individual projects, one measures the value that programs are delivering over time, and one actively tracks dependencies across projects.
Employee EvaluationAgile emphasizes teamwork, and discourages singling out individuals for any purpose. Employee evaluations are considered a no-no in agile environments, because such evaluations create a zero-sum game in which team members are compared with each other. Thus, agile teams are evaluated instead of individuals.
On the other hand, retrospective on all issues - even those pertaining to an individual’s performance - is important. Organizations need to know which employees are the most effective. This is therefore a difficult balancing act that management must play. One consideration is the fact that there is really no such thing as individual performance: people always perform in the context of their team and their work situation. So, for example, if a team member solves a problem, that team member has probably had help from others. No one succeeds all on their own. Thus, it does not really make much sense to view a person’s performance in isolation. Agile therefore downplays individual evaluations, rather than eliminating them entirely.
Employee Skills and RecruitingAgile teams are best composed of generalists - not specialists. Instead of resourcing a team with, say, "A DBA, a Web person, a DB developer, a XYZ buzzword person, etc.", an agile project is best resourced as, "Five developers, who have a demonstrated track record of performance and learning new things".
Interestingly, this is widely recognized in management circles. For example, Greg Scott, CTO at InfraSupport wrote,
"The skill many companies and IT recruiters I've met fail to recognize is the ability and desire to learn. Instead they look for so many years of experience with a specified version of some product. Every true IT pro is behind the curve on specific skill sets and wants to learn new stuff. If companies would embrace the idea of constant learning and invest in it, and really encourage learning instead of giving it lip service, there would be no skills gap.”
Michael Maulick, Managing Partner of Maulick Capital and former CEO of multiple cloud and virtualization technology companies, says it like it is:
"Anytime you put a label on something you doom it into obsolescence. In this discussion I have to blame HR organizations. I think they are failing their companies. From what I see , when it comes to hiring people they don't do HR - they do staffing. Rather that looking for the best possible talent they focus on a tick list of experiences...If you were looking for a someone to solve a complex problem where the solution was needed to be written with Ruby. HR would go out and spec a position where they had to have great expertise in Ruby. Wrong answer ! If I had a complex problem I would go out and find the most competent programmer in the space. Someone that has demonstrated that they can solve complex problems. A good programmer has been adapting as they needed to overtime. Learning a new syntax is nothing. Most great programmers I know have done everything from Assembler, to C to Java, to Perl, to Python, .Net - they keep adapting!"
And then according to Chris Burkhardt, a Senior System Administrator at Medline Industries,
"The IT "skills gap" is a scape goat excuse that represents the uncertaintty of the current business environment much more than it does any generalized deficiencies in the talent pool...If you put out a job posting that says you want 15 years of experience with SAN, ESX, and Mainframes and that they need to be PMP certified with MBA preferred for $80k a year - it isn't a "skills gap" that is causing you to not fill that job it is because Krypton or whatever planet that person may come from hasn't blown up and sent them to our planet yet."
In other words, the thing to focus on when looking for agile team members is an inclination and ability to learn.
And yet, it seems that the trend of hiring for buzzwords continues to wax: “Job Postings For Python, NoSQL, Apache Hadoop Way Up This Year”.
Information SecurityAgile projects cannot tolerate a period during which there is a concentrated non-development effort - such as security testing - that requires development to stop. The waterfall approach of finding security defects and then passing those back to the developers will not work well for an agile project, because the economics of agile rests on continuous development. A separate "phase" for security testing will result in the development team waiting. Security testing will result in many security issues that need to be addressed, and so the agile team will have to be taken out of its wait state and given a list of security issues to fix; the problem is, they have no way to test those fixes except to wait for another security testing phase: thus, the time to complete this phase becomes indeterminate. Agile relies on integrating all kinds of testing with the software development process, so that most tests are automated, and so that there is no separate testing phase at the end. What is really boils down to is creating a process that is continuous, such that working - potentially shippable (secure, and fully tested in a production like environment) - software product comes out the end of each iteration, and such that there are as few manual steps in the process as possible.
The list goes on. Essentially, everything changes under agile.