Slash Content Guide for Website | 6 Challenges to Selling an Agile Project • Slash

In the world of software development and technical solutions products, agile warrants more attention. If so, why the challenges to selling an agile project if its merits warrant a closer look? Well therein lies the conundrum itself. There are a number of different project management approaches that tech teams can use when delivering products for their internal or external clients. The two most common being the waterfall and agile management processes. Waterfall is seemingly easier for the client to grasp and is therefore, often the selected management system. However, allow us to put forth a solid argument for why agile is the project management most often suitable for the job.

Table of Contents

From Waterfall to Agile

To begin with, moving from waterfall to agile means in short going from budget & output centric to real business outcomes. It is necessary to persuade the client to understand that for the project they have, it is not in their interest for this particular project to work in waterfall because the risks for complexity are simply too high. Therefore, at Slash we focus on educating our clients on the value agile has to offer. For instance, the value of additional business outcomes agile presents versus the restrictions faced in waterfall.

Let’s look closely as to why agile adds value where waterfall constricts. For starters, agile uses smaller iterative development cycles over a shorter period of time. These cycles follow a clear path of design > build > test > review and launch. Following the waterfall methodology can leave the client waiting months before anything is delivered whereas with agile, the typical iteration cycle, or sprint, lasts from one to three weeks at most; producing deliverable outcomes for each cycle period.

Agile allows a range of outcomes from features, to user experience, system performance and more whereas waterfall is constricted to a set output of feature A/B/C. That’s not to discredit those features may be necessary or that waterfall is good for simple and/or predictable projects, but the lack of flexibility is the point we want to make here. Business outcomes in real time are more valuable than a simple limited task output.

Moving from waterfall to agile mid project is especially hard when procurement is very traditional; when the client is used to buying a service and predictively knowing exactly what they’re going to get. For instance, let’s quickly step back in time a moment to easily explain this. A typical IT procurement is like buying a copy of Windows 98. I know the cost is $100, and I know exactly what I’m going to get. However, when you’re building an application or system, or custom development of products and systems as we do here at Slash for a startup, enterprise or government system, it’s much more complex than just paying a set cost and getting exactly what you want. Hence why we are focused on helping our clients understand how agile and its ability to anticipate risks & changes in the roadmap can benefit them.

Organization Realignment

The second challenge comes in the form of organizational realignment. No this is not some merger or acquisition where half the staff are shown the door. We’re talking about work practices, methodologies and general mindset or approach to work. Agile requires all parties involved in the product development to be on the same page, especially when it comes to buy-in and commitment from leadership. If the organization has been using waterfall, and you come along to begin a project using agile, realignment of a variety of things will be required.

Realignment to agile is necessary for product organization, that being the people in charge of the product you’re building. Additionally, non-product parties as well like marketing & sales, finance organization, etc. Everyone involved at all levels needs to be aware of the flow and process of agile management.

Moreover the legal contract, an agile contract is innately different from a waterfall contract. For an agile contract we’re essentially saying we think we know what we’re building, based on the client’s needs, and we can break it down into X number of things at X cost. However, this can and may likely change; in the real world of tech development there are unknowns. Therefore, for an agile project we are charging for a retained team, actual days worked per a time sheet, billed on a monthly basis rather than billing for deliverables only.

High Collaboration Mindset

The third challenge we’d like to cover is the need for a high collaboration mindset within not only the delivery team, but also with the broader client organization. Agile is not a “come back in three months” approach; it fundamentally does not and cannot work this way. Remember as mentioned above the sprint iterative development cycles run roughly 1~3 weeks. Therefore, in agile there is a high need for real involvement from stakeholders to join in scrum rituals, maintain an open dialogue and mindshare. That dialogue doesn’t just happen on its own and naturally faces challenges as not all parties involved come from the same backgrounds or for that matter are native English speakers; everyone from stakeholders to engineers need to be engaged, creating a cultural chemistry, customs and communication.

Now in order for all this collaboration to take place we need to ensure that the proper tools are in place otherwise it’s all for naught. The tools should be in line with the client’s compliance requests for privacy and data security. In agile you will reach a deep integration between multi-disciplinary teams from business design/owner to product design to software engineering and more; hence, these tools become vital to the intense collaboration effort that takes place.

Requirements Engineering & Backlog Grooming

For challenge number four we come to requirements engineering and backlog grooming. Requirements engineering, as the name suggests, is the ability to extract the requirements or specifications from a business need and product design considerations. This means you understand the client’s wishes, the business’s functional needs, and also the design considerations of those functional needs.

For requirements engineering we define epics, that is a collection of features that get broken down into user stories. User stories get evaluated based on their complexity and the man hours needed to complete them. This becomes part of the backlog grooming as we can prioritize both the user and system stories for development. Large stories that conceptually have not yet been broken down present a commercial and technical risk, and need to be defined into smaller pieces. If the client asks us to build an app, and when we ask some detailed questions they cannot tell us the full detail of a feature, the feature is likely a large or even extra-large story. To characterize the size of a story, we use T-shirt sizes at Slash (from XXS to XXL).

This gives us the ability to breakdown any functional needs through our requirements engineering process. Typically our requirements engineering process is delivered as a continuous integrated capability within an agile delivery squad. That means when using agile you are continuously conducting this process for the engineering, design, delivery and shipment of the product. Again stressing the previous point that agile demands a high collaboration mindset as this point cannot be efficiently or effectively done without it. As a result of all this we can continuously add value to the client using agile; if you can’t do this, you can’t do agile properly.

Reconciling Payments

Naturally a contract specifies a mechanism for billing, and herein lies the fifth challenge to selling an agile project, especially in a client-vendor relationship though to some degree the same challenge exists in an intra-company billing arrangement. One option is to use a traditional timesheet organized so the number of days multiplied by a set day rate defines the development team’s cost. At the end of the month you reconcile said timesheet and bill this to the client. Of course, any potential disputes need to be resolved. The risk herein is that reconciling a timesheet and issuing invoicing is a time-consuming process that ultimately results in payment delays; not to mention the administrative overhead cost.

Here at Slash we advocate for improving this by including what we call a “predictable monthly billing schedule” into the contract; the amount will then be decided and agreed upon. This allows everyone from the client side and Slash to appropriately plan their cash flow and expenses. Moreover, at the end of the project you can reconcile the difference between the contractual monthly billing and the actual timesheet consumed; the difference is then easily settled.

BONUS: Concept design and user testing

Finally in an environment of continuous design and delivery, it is critical that a client has sufficient understanding and organizational consensus on the given product solution they wish to implement, and user validation that indeed the product would solve the user problem.

Often, concept design and validation is taken out of the hands of the agile delivery teams that need to design and deliver the product. That’s fine and there are legitimate reasons to keep the business design team as a standalone function: problem researchers, design researchers, business analysts, venture builders are after all specialist roles. They focus on identifying the problem, conceptualizing a digital product solution that solves the problem and finally validating with users that it does. The insights from such a concept validation sprint, or sometimes called ideation and rapid prototyping, is then captured into a design brief for the agile delivery team to take over for detailed design and build.

However, what’s often lacking is a deep integration between the business design and agile delivery team to ensure a predictable yet flexible, continuous R&D cycle, every step along the way, from concept to delivery. Establishing such a workflow and capability is the holy grail of digital R&D teams for digital innovators in startup, corporate and government teams.

Such a workflow is heavily dependent on creating an agile delivery organization that has solved the 5 challenges outlined above, so it can take on this 6th challenge with confidence.