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.
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
methodologies. Spoiler, engineering is far better poised for the transition than the business.
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:
Improve customer satisfaction through “continuous” delivery of software
Deliver working software frequently
The business and developers must engage daily throughout the project
Build projects around motivated individuals
The most effective means of communicating within the development team is face-to-face
Working software is the primary measure of progress
Agile processes promote sustainable development
The sponsors, developers, and users should be able to maintain a constant pace indefinitely
Continuous attention to technical excellence and good design enhances agility
Simplicity — the art of maximizing the amount of work not done — is essential
The best architectures, requirements, and designs emerge from self-organizing teams
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:
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
management that demands that business stakeholders define deliverables (stories) and effectively
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
= 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.
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.
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.
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.
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
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.
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
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.
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.