The Value-Up Paradigm

The paradigms I’m going to contrast are how we view the entire development process. I will refer to two different paradigms: the first is the “work-down” approach which I will contrast with the “value-up” approach. I read about this in Software Engineering with Microsoft Visual Studio Team System concerning the new Microsoft approach to software development including an introduction to the Agile SDLC. However, I’m not here to promote Microsoft Team System or Agile methodology; instead, I’m here presenting a paradigm that is pertinent regardless of your chosen SDLC or technological platform.I will start by defining both the work-down and value-up approaches (and I will use “approach” and “paradigm” interchangeably), outlining the effects of both paradigms, and I will finish with ensuring that this paradigm becomes practical in your daily development tasks.

The Old, Work-Down Approach

Most of us are very familiar with this approach. We meet with the prospective client, define requirements as much as possible, and approach the development task as marking off completed requirements until completion. This methodology works fine when you have no scope creep, have low risk, and well-defined requirements; but unfortunately this doesn’t describe most of our projects. This is especially true for us that freelance as the risks involved for us are much higher.

A project manager typically has three variables to use in the work-down approach: time, resources, and functionality. What has happened is that a fourth area needs to be recognized-namely, quality. Due to this and the truth that most of our project managers don’t take quality into account as one, if not the, most important attributes of successful software development from the very beginning.

The Value-Up Approach

When approaching this paradigm we need to remember what most satisfies us when we make a purchase. Even though we might not consciously think of it, when we make a purchase we are intending the purchase to return value to us in one form or another. I am most satisfied and suffer less cognitive dissonance when I see the value received from my purchase.

In the never-ending process to ensure that our customers are satisfied we should view their investment in us as a desire to receive value of some kind. Concentrating on a consistent flow of value to the customer should be a paradigm that will utilize, but we must not internalize as we must also convey that emphasis to our customer.

Software development is also different than other forms of development. For instance, when building a bridge there is no intrinsic value in a bridge that is only half-way done! But in opposition to this, software development isn’t build along the same vein. My customer can receive benefit by starting to use an application even though the interface is not yet completely finished. The earlier our customers see value being delivered to them the happier they will be throughout the process. Even though I’m not endorsing an agile approach to software development, this approach, when combined with agile iterations can help you effectively deal with the inevitable scope creep.

Contrasting the Paradigms

The book lays out a table to visually see the impact of using the paradigms (of which I will use the majority of the table), and the information is verbatim from the book (pgs. 6–7). While not exhaustive, it will help us to see tangible results of making such a change.

The first thing to realize is that in a value-up paradigm we embrace that changes happens throughout the software development process. I’m sure we have all had our fair share of frustration when we complete tasks according to the original specifications, but when we from the beginning perceive change throughout the process as inevitable-and ultimately positive-then it makes the process much easier for us.

Notice as well that the only true values of progress measurements are items that actually give value to the customer. In other words, our Gantt Chart should reflect tasks that actually give value to the customer not only tasks completed. In the context of a web application, that might be the installation and/or customization of a content management system, maybe it might be the ability for the user to customize the interface, or it could be a litany of other items. The only thing our customer should hear from us is that we are delivering value and utility to them throughout the process. This also helps when our customer comes to us and says something like: “This doesn’t do what the requirements outlined.” Well, in our perception it might be what the requirement stated, but if value is not given to our customer then we haven’t made any progress.

I do understand that there is variance that, no matter how much you try and avoid, conflict happens over what requirements. But the adage, “the customer is always right” is still very applicable to software development.

Moving from the Ethereal to the Practical

Now that we have outlined the philosophy we must ask how this can be of practical value to us in our everyday work. The best way to bring this back down to earth is to share a practical example.

I get to do software development with government agencies (Air Force, USAID), and if any of the readers share that experience then they understand my pain and frustration. More than any other clients, government agencies are some of the hardest to work with. The paradigm for development in general, whether software or weapons development, is the traditional (non-agile) methodology of outlining all the requirements from the beginning down to the type of paper you’ll submit to them.

These government agencies are familiar with only seeing something when the developer feels it’s presentable, and updates are traditionally provided in terms of a work down paradigm. I had to, with some very conscious thought, change the way I conversed with my customer. Here are some examples of changes I made in conversing with my customer. The first list will be the traditional way of conveying progress, and the second list will be the verbiage I changed from a value-up paradigm.

Work-Down Terminology

• Per the requirements documentation, we have completed 1.A, 1.B, and 2.A.
• Your new requirements are not in the original document so we will have to stop and revisit the documentation.
• We have successfully completed the project according to the requirements.

Value-Up Terminology

• With the completion of this iteration, you can now dynamically edit your content, customize the layout, and you can start to see how it will function as we finalize the user interface.
• New requirements are a natural part of the process, and we will focus on your new requirements in the next iteration.
• We have successfully completed the project in light of your desired capability.

Conclusion

The value-up paradigm is a powerful way to approach software development, but change is something that needs conscious focus. The value of changing paradigms will become evident nearly instantaneously as the relationship improves between you and your customer, and the reputation of your company as one that delivers tangible value early grows and supplies a constant flow of work.

You can view the slides for my original presentation on SlideShare.