You’ll have no doubt heard all the buzz around Agile and most likely, dismissed it as an exclusive tool for developers. While that has long been the perception, more and more businesses are finding the Agile methodology succeeds best when everyone is pulling in the same direction. Changing how a business thinks through its process is not a trivial thing, but one that is a worthwhile endeavor.

I have been through the agile adoption process as a key stakeholder of the business. I have seen how an organization will need to evolve when considering the same. In this article I am going to discuss Agile, from the lens of the business.

When should I consider Agile as a business stakeholder?

We frequently encounter small to midsize companies re-imaging their product offering and architecture for scale, growth, and revenue generating opportunities. To rebuild the underlying platform running your business — one that may have taken years or decades to build — can be a daunting task. This is when the leadership team begins to consider Agile development methodologies. At its core, it is an approach to project management, usually but not exclusively applied to software development, that:

• Enables an incremental approach to larger projects so that value can be realized sooner

• Improves collaboration between developers and client

• Ensures that failure is not catastrophic but can inform subsequent deliverables in the project timeline through frequent releases

• Makes a monumental project consumable

What follows are thoughts regarding key challenges small to mid-sized companies face when adopting Agile methodologies. Spoiler, engineering is far better poised for the transition than the business.

What I need to know about Agile as a business stakeholder?

In the beginning … there were 17 software development representatives across various disciplines who were really tired of hearing it’s late”, “this is not what I requested”, “that initiative was 12 months ago and I’ve moved on” (to the newest shiny object).

So these 17 disciples ascended the Mount, and not to be outdone by Moses, descended from the ethereal heights with 12 (in your face Moses) principles to guide development. This became the foundation for the Agile approach. Read the following at your leisure or skip ahead. No skin off my back. Maybe you already know everything about Agile Principles:

1. Improve customer satisfaction through “continuous” delivery of software

2. Deliver working software frequently

3. The business and developers must engage daily throughout the project

4. Build projects around motivated individuals

5. The most effective means of communicating within the development team is face-to-face

6. Working software is the primary measure of progress

7. Agile processes promote sustainable development

8. The sponsors, developers, and users should be able to maintain a constant pace indefinitely

9. Continuous attention to technical excellence and good design enhances agility

10. Simplicity — the art of maximizing the amount of work not done — is essential

11. The best architectures, requirements, and designs emerge from self-organizing teams

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

These are the core principles that underlie the many varying approaches to Agile. And there are many, with some existing outside the realm of software development. Now that the foundation is under us, let’s focus on the point of this article.

The 12 guiding principles described in the Agile manifesto are really nothing more than a set of common expectations associated with technology development outcomes, though other industries with complex projects have leveraged Agile effectively.

Technology teams generally find Agile adoption rooted in familiar processes and tend to take to it like a duck to water. The business on the other hand, tends to have an outweighed impact on successful transition to the Agile model and can struggle to stay afloat as many of the changes are behavioral in nature and are prone to back sliding. For this reason, it is critical to obtain buy in from the business and invest a little extra effort to bring them along on this journey.

As technology resources quickly adapt to this new world, six key factors that should be addressed through any coaching process relative to the business should include:

1. Discipline of Self

The realization that the days of picking up the phone and reaching out to developers/technology leadership with enhancement requests expecting immediate results are over. At its core, Agile is project management that demands that business stakeholders define deliverables (stories) and effectively assign the relative benefit and priority for each request. Eleventh hour requests can circumvent all of the planning and cultivation that went into creating the list of stories associated with that sprint (sprint = small window of time to accomplish said deliverables, typically two weeks). Consecutive sprint disruptions can bring a large project to a screeching halt. This is why the executive team must be supportive of this approach and actively encourage accountability on both sides of this equation.

The quickest way to instill this is through the inclusion of the key business stakeholder(s) in the entire Agile process. This starts with sprint planning. Once the stakeholder commits time to defining the list of expected stories that will be included in a development team’s (scrum team) sprint, then they become invested in their completion and will be far more cognizant of the impacts of re-prioritization within a sprint.

2. Discipline of Thought

The business plays a critical role in ensuring the development team is tackling the appropriate tasks. This means they cannot dump a list of product enhancements and expect delivery without first defining the relative value of each as well as a reasonable assessment of impact to the business (mission critical vs. nice to have). If the stakeholder must commit time and energy to prioritizing the list and buys into the level of effort required to complete each task, they will feel a sense of ownership. This serves to eliminate the “us” versus “them” mentality that permeates too many business/engineering relationships. The business needs to stop throwing items over the wall and scapegoating engineering when the wrong things, or worse, no things are delivered.

3. Discipline of Purpose

Business requirements must be fully developed and approved by key stakeholders before any item is included in a sprint. I may have been guilty of delivering post-it note sized requirements in the past. I get it. This takes effort but how can you ever be satisfied with the delivered product if you don’t take a few minutes to figure out what the hell you want in the first place. Suck it up.

4. Discipline of, why the hell did I start this Discipline sub heading..UAT?

The business is responsible for user acceptance testing (UAT). Failure to review in a timely manner will delay migration to production and adversely impact delivery of subsequent requests. Again, inclusion of stakeholders in the sprint planning and review processes helps to create buy in.

There comes a time in every sprint called sprint demo day. This is when key stakeholders and engineering teams gather to review all that was accomplished in the most recent sprint. If the engineering team was scheduled to review and demo their most recent release but cannot because the business was unable to validate the finished product, then there should be a compelling reason for failure to complete UAT. Repeated failures by a business area to address this or any other area of responsibility within the Agile discipline will serve to undermine the relative priorities of their deliverables as development efforts are focused on more engaged functional areas. Inclusion of executive team members in sprint demos can ensure this critical function gets the attention it deserves. Saying “we did not fulfill our UAT obligations” in front of the executive team has a way of working itself out pretty quickly.

5. Discipline of Vision

Each functional area needs to understand that they are not the entire business and while one business unit’s item may be their most important, it may not be the most important to the overall business. Again, this is where the executive team can have a significant and lasting impact on Agile adoption.

A word of caution, this can be a source of contention that the executive team must watch very carefully. If the focus of sprint after sprint is on new product development (a.k.a. revenue generating initiatives) while enhancements/fixes are never prioritized, you will quickly alienate the functional or operational areas of the business. Agile will become a source of resentment and feed feelings of departmental inferiority.

6. Discipline of Time

The business must understand that there are only so many available hours in a sprint and that these hours must be carefully cultivated to ensure efficient allocation of resources. At the same time, Engineering needs to define the ratio of development to maintenance hours so that as “keep the lights on” issues emerge, there are resources and hours available to address these business critical priorities.

Again, stakeholder inclusion in the sprint planning process does more to further this objective than anything else can. As they witness, discuss, debate, and prod for insight into the level of effort assigned to stories, they gain a much better understanding of the effort required to achieve the end goal. The flip side of that coin is that a well educated user will be less accepting of seat-of-the-pant effort estimates that tend to be padded to ensure on time completion. I’m talking to you engineers. You know who you are.

Agile WILL be worth the effort of adoption

I know this may sound like I’m tearing the business a new one here, but as I have been guilty of failing at each of the above at some point, I feel qualified to speak to their impacts on this process. To all the Engineers who struggled to keep me within the bounds of a well defined sprint, I humbly request your forgiveness.

As for those considering adoption of Agile methodologies, this is NOT an engineering initiative. This is a business discipline that can be regimented, demanding and prone to failure but capable of delivering meaningful and lasting value.

The effort of adoption will be worth it if the business embraces agile methodologies as fully and openly as those who dwell in the realm of the technical arts.