At some point during the transformation of an organization to Agile Development, I hear a sentence that always lets me know that the organization is making important progress in their transformation.

“Wow,” they say, “I didn’t know it would touch so much of the company!”

I’ve heard this phrase uttered at some point by almost every customer I’ve worked with so far, even when I go out of my way to warn them in advance. But what do they mean and what causes them to say this?

Even when you look at the Agile Manifesto, the overall impact of agile is not so much downplayed as ignored. “We are uncovering better ways of developing software…,” the manifesto says. Perhaps the original signers weren’t thinking about it. Perhaps they said it without saying it. Whether calculated or a misstep, the truth is this – when you make the decision to transition to Agile Development, you are making a decision that will affect your entire company.

Software Engineering is All About Change

Agile Development’s broad impact comes from the fundamental truth that building software is not something that can be scripted to the last detail, with contingency plans and risk management handling all that could possibly go wrong or change during the development effort. The manifesto practically screams this in every value statement.

• “We value working software over comprehensive documentation.” Why? Because documentation isn’t the same as real, working software. The customer can’t always look at documentation and understand how the software will work and know if they will like it. Frankly, many developers will tell you that no software is guaranteed to work until it is written, and even then there may be doubt.
• “We value customer collaboration over contract negotiation.” Why? Because customers frequently don’t know what they want until after you start building the product. Contracts can set the basic boundaries and conditions, but you can’t lock more than the highest-level functional descriptions in a contract.
• “We value responding to change over following a plan.” Why? Because we know change is gong to occur. It’s inevitable. More than that, some change is absolutely necessary (e.g., changes to the architecture when the product doesn’t scale properly) and some change is absolutely valuable (e.g., an outstanding new feature that can be introduced to the market before the competition can get it there).

Dealing with Change the Agile Way

So, how does Agile Development, as it recognizes the change-ridden reality of software engineering, affect the organization? Let’s look at the overall impact at a high level as a series of causes and effects with regard to requirements engineering:

• Agile teams set their expectations for an iteration at the beginning of the iteration. They are encouraged NOT to set their commitment or forecast earlier than this because of the possibility that what the are building may change as late as the day immediately preceding the iteration. The earlier the team commits before the iteration begins, the more the risk that something may change prior to the iteration start date. Risk creates a greater likelihood of waste (decreased return-on-investment).
• Because Agile teams commit just before the iteration, and to avoid similar risks, Product Owners commit less feature detail to writing until the team is actually ready to build. Of course, this should not be interpreted as NO detail – many Product Owners encourage the identification of and documentation of test cases, acceptance criteria, and a high level description when the “story” is originally written. To the extent, however, that Product Owners are not writing pages and pages of requirements specifications, they are protecting against wasted work caused by changes to the requirements, incorrectly documented requirements, and incorrectly interpreted written requirements. They are also protecting against the risk of de-scoped requirements, re-prioritized requirements, and requirements deleted from the product backlog altogether.
• Because Product Owners commit less feature detail to writing, project management must learn to work with less detail before and during the project. Features are sized, ordered, budgeted, and scoped based on high level descriptions and statistically-sound (and deliberately imprecise) estimates. In other words, we start every project with an educated guess as to what we can finish during the project and then we manage the project to achieve at least what we guessed. Contrast this with the waterfall approach that if we plan everything, we can predict with certainty what will be finished by the end date.
• Because project content is known to fluctuate, department level budgeting and resource planning becomes less about the “precision” of the waterfall project schedule and skills projection and more about the business value of the features currently scoped in the project and carefully managed during the project. We project the skills we need based on the features on which we believe we will work. In addition, content fluctuation means we have to deal with customers differently, by changing how we make commitments to them, changing how we contract with them, changing how we accept changes from them during the project, changing how visible the project is to them and changing how our development teams interact with them.
• Because of the changes in how we deal with customers, both our legal and our sales & marketing departments need to be involved in identifying changes to contracting and other practices and then making those changes and enforcing them afterward.
• As a result of changing requirements, shifting skill needs, and interaction with customers, teams need to before able to adapt quickly to feedback from the customer and the Product Owner. To support this, we in the Agile world expect our teams to be sufficiently self-managing and self-organizing that they can handle the day-to-day operations of the team as well as being able to quickly respond to new and changing requirements without unnecessary delay (waste).
• Because our teams need to be more self-managing and self-organizing, management in the company needs to become more coaching-oriented (with regard to the teams) rather than more decide-and-direct-oriented. Management must learn to deal with their development teams as long-term, independent structures, taking their development priorities from the Product Backlog and coaching them toward better technical skills, teamwork, collaboration, and problem solving. Performance must be measured at the team level, rather than being focused solely on the individual. Team members must be hired based first on their team skills and ability to learn and second on their technical prowess.
• Because we need to look at performance management from the team perspective, our approach to performance management must change (many suggest radical changes in performance management). Companies have to learn how to elevate the performance of the team, not the individual.
• Because we need to focus more on team coaching and less on decide-and-direct, our management team needs to learn and exercise team leading and team management skills they might not have even exercising enough in the past.
• Because our focus will need to shift from technical prowess to include a focus on team skills, our hiring practices need to change. How we write job descriptions, promote the company in the local media and even how we phone screen and interview will need to change.

To work properly, Agile Development many aspects of how a business operates. In this section, we looked only at requirements management and engineering and showed how practices in the area can quickly impact more and more of the business operations.

Rewriting the Organization

As you can see in the previous section, Agile Development is more than writing code. In just this brief (and hardly exhaustive) summary, we’ve impacted

• Software Development
• Product Management
• Requirements Management and Engineering
• Project Management
• Department budgeting
• Resource planning
• Customer relationship management, contracting
• Human Resources and hiring practices
• Management and coaching skills
• Performance management

Certainly, should your organization feel that they just can’t risk Agile on the entire organization, your approach to Agile can be constrained to just your development organization. However, your implementation of Agile will be exactly that – constrained. It’ll be like hammering square pegs into a bunch of round holes — they won’t fit and it’ll always be awkward.

Now, be honest; does an awkward implementation of anything sound like a good idea for your organization? If not, plan your transition to Agile Development for the long haul. It’s more than just code. Treat it that way.