Agile development and its related methodologies and practices have long been viewed as something that “developers do” with no consideration given to the broader impacts of those processes on the organization as a whole.  This, incidentally, is also the primary cause of failures on the part of organizations who attempt to implement Agile practices — the belief that all that’s changing is how the developers create, test, and deploy their code, and everyone else in the company proceeds on with business as usual.

Unfortunately, such a belief is far from the truth — in reality, companies who change from a rigorous, planned product process to an Agile process have to face the fact that they have to change the way they do business from the ground up, if they expect to gain the benefits of those changes across the board.

Business Benefits of Agile

Before we talk about how the various teams and groups within a company are affected by a switch to Agile practices (including Scrum, Extreme Programming, or even Kanban), let’s talk a little bit about the benefits to the business as a whole that come from such approaches:

• Increased Visibility and Input
  One of the hallmarks of Agile practices is the intent that they are entirely transparent to anyone in the company who wishes to pay attention to them.  Scrum and Kanban boards are intended to be placed in a visible and accessible location, such that anyone can see where a project or task is in the process at any time.  And the same should be done with backlogs and user stories — remember, Agile values individuals and interactions over processes and tools, and it’s in taking advantage of those interactions that the business can have a better idea of what’s actually going on than they can in reviewing weekly status reports where everything is always “green”.
• Regular Feedback Loops
  Another hallmark of Agile practices is the ability of the business to know what parts of an effort have been completed as they are done and to review those achievements with the teams that worked on them in a collaborative environment.  This happens because Agile values working software over comprehensive documentation and customer collaboration over contract negotiation — nothing is better than actually seeing something working for eliciting feedback and insights from the business as a whole, and nobody is better at providing that feedback than actual customers or at least the people who work closely with them on a day-to-day basis.
• More Flexibility to Respond to Customers and the Market
  The most obvious aspect of Agile that the business benefits from is the ability to respond quickly to changes that may happen to your customers or in your market.  When you’re working off of a flexible and prioritized backlog of work items, rather than a 12-24 month pre-defined plan, you can easily and seamlessly alter that backlog so that what’s important right now becomes the next thing that the teams can work on.  Valuing response to change over following a plan means that teams must be flexible in their approach and in their commitments, so that when that next innovative opportunity opens up, they (and the company) can take advantage of it.

Now that we understand some of the high-level benefits a business can gain from a move to Agile, we can discuss how that affects some of the specific business stakeholders and practices that all organizations have to manage.

How Strategic Planning Changes for Agile

Perhaps the biggest change that an organization must accept when adopting an Agile approach is that their strategic planning has to adjust to fit the process.  You simply can’t have a 24-month plan with specific deliverables slotted in, staffed, and committed to, and still practice Agile development successfully.  And if you stop and think about it, and are entirely honest with yourself, you could probably look at that 24-month plan and admit that half of what’s on there won’t get done because it’s too much work, it won’t be needed or wanted, or it’s just there to make some outside party (a customer or investors) happy.  And all of those are the wrong reasons to have something on a plan or a roadmap.

Agile processes actually allow us to engage in real strategic thinking — the long-term “plan” for an Agile company and team is a vision of a possible future, not some line-item checklist of stuff we want to do, that we think people might want in two years.  And this is what makes the change so scary for some organizations — because they don’t really have a strategy, and a transition to Agile literally forces them to confront this scary fact.

The long-term plan for an Agile organization is a vision of a possible future.

But it’s not that scary — as I mentioned in an earlier article on designing Agile roadmaps, you can still have things that you’re committed to delivering.  It’s just that the time-horizon that you can claim to be certain about is far more reasonable — it’s 2-3 months at most, rather and 12-24 months.  And once you realize that this is a freeing approach — that it allows you to understand what your company’s (and products’) strengths, weaknesses, and opportunities are — then you can create something that’s far more motivating across the organization than your old 24-month roadmap (which, by the way, nobody outside of your management team actually believes).

How Marketing and Sales Change for Agile

Obviously, one can’t change their strategic planning process without having some pretty significant impacts on how they position and sell their company and their product.  And the teams outside of Development who are probably the most susceptible to problems related to an Agile implementation are the Sales and Marketing teams, who often work off of a 12-24 month plan to achieve their goals.

So, if we don’t have that plan, how do we manage those needs?  One thing that needs to change is that Sales has to move from a feature-based selling model to a value-based selling model, if they haven’t already.  This is because feature-based selling fails if you don’t have that long-term list of features that you can commit to in front of your customer.  If your sales people can’t sell your product as it is, and with perhaps the current set of in-development features, then you have a massive problem on your hands that needs to be dealt with anyway — Agile practices or no.  Again, as with the fear of realizing  you have no strategy, realizing that you have no value to sell to your customers can be a scary thing.

Fear should be an agent of change, not a paralyzing force.

But the most important thing to remember is that fear is an agent of change, not something that should paralyze you and cause you to delay the inevitable.

Similarly, marketing needs to adjust its rhythm, cadence, and messaging to accommodate the changes in release cycles and in long-term predictability that you’re likely to encounter.  And they can’t sit in their silo and run things from behind a glass curtain — if there are specific timelines or deliverables (such as industry trade shows), they need to be proactive in communicating these to the Product Managers and development teams, so that efforts can be specifically focused on those events when necessary.  Marketing needs to embrace newer technologies and marketing channels so that they can be more capable of “shooting from the hip” when an important feature comes through, and they also need to understand that there’s no harm or foul in separating product releases from marketing releases or announcements — some new feature can, in fact, exist in the product before it is officially announced or positioned.

How Support and Documentation Change for Agile

It’s a very, very common myth that Agile means “no documentation,” which stems from a vast misunderstanding of one statement in the Agile manifesto (and the face that developers would often rather “do” than they would “document”).  Agile simply values working software over comprehensive documentation — this doesn’t mean that there is no documentation or that documentation isn’t necessary, and it’s primarily focused on the development teams and not externally-facing documentation, which may be necessary prior to deployment of software.

Agile does not mean “no documentation” — it means the minimum amount necessary.

The primary change that Support and Documentation teams need to deal with when a shift to Agile is in the works is the realization that they’re not going to have a comprehensive, line-item accurate requirements document that they can use to start their work or to support their work.  Rather, these teams are going to need to collaborate with the Product Owner to ensure that they have access to testing environments, user stories, and possibly even code check-in notes, so that they have the visibility that they need to do their jobs the most effectively.

And these teams, just like Marketing and Sales, need to work carefully with the Product Management team so that the PM team can ensure that their specific needs are addressed, and that product isn’t shipped until or unless it’s really “ready” — and if that means that code sits while user or support documentation is written, that’s okay.  It’s not optimal, and it’s something to focus on resolving, but it’s okay.

Agile Means Collaboration — From Everyone

Overall, the theme here should be clear — Agile’s focus on collaboration, results-oriented delivery, and customer focus is something that every aspect of the business has to adjust to and be actively involved in.  Agile is not just a development methodology; it’s a business process that changes every input and output to and from the development teams.