The Value-Up Paradigm

The par­a­digms I’m going to con­trast are how we view the entire devel­op­ment process. I will refer to two dif­fer­ent par­a­digms: the first is the “work-down” approach which I will con­trast with the “value-up” approach. I read about this in Soft­ware Engi­neer­ing with Microsoft Visual Stu­dio Team Sys­tem con­cern­ing the new Microsoft approach to soft­ware devel­op­ment includ­ing an intro­duc­tion to the Agile SDLC. How­ever, I’m not here to pro­mote Microsoft Team Sys­tem or Agile method­ol­ogy; instead, I’m here pre­sent­ing a par­a­digm that is per­ti­nent regard­less of your cho­sen SDLC or tech­no­log­i­cal platform.I will start by defin­ing both the work-down and value-up approaches (and I will use “approach” and “par­a­digm” inter­change­ably), out­lin­ing the effects of both par­a­digms, and I will fin­ish with ensur­ing that this par­a­digm becomes prac­ti­cal in your daily devel­op­ment tasks.

The Old, Work-Down Approach

Most of us are very famil­iar with this approach. We meet with the prospec­tive client, define require­ments as much as pos­si­ble, and approach the devel­op­ment task as mark­ing off com­pleted require­ments until com­ple­tion. This method­ol­ogy works fine when you have no scope creep, have low risk, and well-defined require­ments; but unfor­tu­nately this doesn’t describe most of our projects. This is espe­cially true for us that free­lance as the risks involved for us are much higher.

A project man­ager typ­i­cally has three vari­ables to use in the work-down approach: time, resources, and func­tion­al­ity. What has hap­pened is that a fourth area needs to be recognized-namely, qual­ity. Due to this and the truth that most of our project man­agers don’t take qual­ity into account as one, if not the, most impor­tant attrib­utes of suc­cess­ful soft­ware devel­op­ment from the very beginning.

The Value-Up Approach

When approach­ing this par­a­digm we need to remem­ber what most sat­is­fies us when we make a pur­chase. Even though we might not con­sciously think of it, when we make a pur­chase we are intend­ing the pur­chase to return value to us in one form or another. I am most sat­is­fied and suf­fer less cog­ni­tive dis­so­nance when I see the value received from my purchase.

In the never-ending process to ensure that our cus­tomers are sat­is­fied we should view their invest­ment in us as a desire to receive value of some kind. Con­cen­trat­ing on a con­sis­tent flow of value to the cus­tomer should be a par­a­digm that will uti­lize, but we must not inter­nal­ize as we must also con­vey that empha­sis to our customer.

Soft­ware devel­op­ment is also dif­fer­ent than other forms of devel­op­ment. For instance, when build­ing a bridge there is no intrin­sic value in a bridge that is only half-way done! But in oppo­si­tion to this, soft­ware devel­op­ment isn’t build along the same vein. My cus­tomer can receive ben­e­fit by start­ing to use an appli­ca­tion even though the inter­face is not yet com­pletely fin­ished. The ear­lier our cus­tomers see value being deliv­ered to them the hap­pier they will be through­out the process. Even though I’m not endors­ing an agile approach to soft­ware devel­op­ment, this approach, when com­bined with agile iter­a­tions can help you effec­tively deal with the inevitable scope creep.

Con­trast­ing the Paradigms

The book lays out a table to visu­ally see the impact of using the par­a­digms (of which I will use the major­ity of the table), and the infor­ma­tion is ver­ba­tim from the book (pgs. 6–7). While not exhaus­tive, it will help us to see tan­gi­ble results of mak­ing such a change.

The first thing to real­ize is that in a value-up par­a­digm we embrace that changes hap­pens through­out the soft­ware devel­op­ment process. I’m sure we have all had our fair share of frus­tra­tion when we com­plete tasks accord­ing to the orig­i­nal spec­i­fi­ca­tions, but when we from the begin­ning per­ceive change through­out the process as inevitable-and ulti­mately positive-then it makes the process much eas­ier for us.

Notice as well that the only true val­ues of progress mea­sure­ments are items that actu­ally give value to the cus­tomer. In other words, our Gantt Chart should reflect tasks that actu­ally give value to the cus­tomer not only tasks com­pleted. In the con­text of a web appli­ca­tion, that might be the instal­la­tion and/or cus­tomiza­tion of a con­tent man­age­ment sys­tem, maybe it might be the abil­ity for the user to cus­tomize the inter­face, or it could be a litany of other items. The only thing our cus­tomer should hear from us is that we are deliv­er­ing value and util­ity to them through­out the process. This also helps when our cus­tomer comes to us and says some­thing like: “This doesn’t do what the require­ments out­lined.” Well, in our per­cep­tion it might be what the require­ment stated, but if value is not given to our cus­tomer then we haven’t made any progress.

I do under­stand that there is vari­ance that, no mat­ter how much you try and avoid, con­flict hap­pens over what require­ments. But the adage, “the cus­tomer is always right” is still very applic­a­ble to soft­ware development.

Mov­ing from the Ethe­real to the Practical

Now that we have out­lined the phi­los­o­phy we must ask how this can be of prac­ti­cal value to us in our every­day work. The best way to bring this back down to earth is to share a prac­ti­cal example.

I get to do soft­ware devel­op­ment with gov­ern­ment agen­cies (Air Force, USAID), and if any of the read­ers share that expe­ri­ence then they under­stand my pain and frus­tra­tion. More than any other clients, gov­ern­ment agen­cies are some of the hard­est to work with. The par­a­digm for devel­op­ment in gen­eral, whether soft­ware or weapons devel­op­ment, is the tra­di­tional (non-agile) method­ol­ogy of out­lin­ing all the require­ments from the begin­ning down to the type of paper you’ll sub­mit to them.

These gov­ern­ment agen­cies are famil­iar with only see­ing some­thing when the devel­oper feels it’s pre­sentable, and updates are tra­di­tion­ally pro­vided in terms of a work down par­a­digm. I had to, with some very con­scious thought, change the way I con­versed with my cus­tomer. Here are some exam­ples of changes I made in con­vers­ing with my cus­tomer. The first list will be the tra­di­tional way of con­vey­ing progress, and the sec­ond list will be the ver­biage I changed from a value-up paradigm.

Work-Down Ter­mi­nol­ogy

• Per the require­ments doc­u­men­ta­tion, we have com­pleted 1.A, 1.B, and 2.A.
• Your new require­ments are not in the orig­i­nal doc­u­ment so we will have to stop and revisit the documentation.
• We have suc­cess­fully com­pleted the project accord­ing to the requirements.

Value-Up Ter­mi­nol­ogy

• With the com­ple­tion of this iter­a­tion, you can now dynam­i­cally edit your con­tent, cus­tomize the lay­out, and you can start to see how it will func­tion as we final­ize the user interface.
• New require­ments are a nat­ural part of the process, and we will focus on your new require­ments in the next iteration.
• We have suc­cess­fully com­pleted the project in light of your desired capability.

Con­clu­sion

The value-up par­a­digm is a pow­er­ful way to approach soft­ware devel­op­ment, but change is some­thing that needs con­scious focus. The value of chang­ing par­a­digms will become evi­dent nearly instan­ta­neously as the rela­tion­ship improves between you and your cus­tomer, and the rep­u­ta­tion of your com­pany as one that deliv­ers tan­gi­ble value early grows and sup­plies a con­stant flow of work.

You can view the slides for my orig­i­nal pre­sen­ta­tion on SlideShare.