Would You Rather Plan For Risk or React To Circumstance

I was asked recently by someone I greatly admire and respect, “Wouldn’t you rather plan for risk than react to the circumstances that befall your project?”

At the time I was stumped.  Yes I guess I would, but we can’t see everything can we?  At least I can’t.

In reflection my answer is: I would rather do both.  See and plan for those risks I know  and use a daily scrum-like meeting to capture what I cannot plan for.

What are your thoughts?

The Agile Management Fad

Is Agile a management fad?  Is its blistering adoption throughout the world rooted in a proven value driven approach or the hysteria of the masses clamoring for a new trend to profit from and identify with?

Fad – defined

According to Wikipedia a management fad has certain characteristics. Let’s look through these defining elements and see if Agile can fit this definition.

1. New Jargon for Existing Business Processes?  Seems that there are plenty of examples that fit this like:

Manifesto = Mission

User Story = Requirement

Planning Poker = Estimating

Daily Scrum = Daily 15 minute meeting

Scrum Master = Coordinator/Facilitator with no authority.

2. External Consultants Who Specialize In the Implementation of the FadWould anyone deny that agile has these in abundance?  Agile consultants are everywhere and firms specializing in agility are in no short supply.

3. A certification or appraisal process performed by an external agency for a fee.  Yep. Many of these exist. Although they don’t all agree with one another on the merits for earning that certification, CSM, CSP, PMI-ACP, and the icAgile body of certifications represent a diversity of vehicles for achieving formal certification.

4. Amending the job titles of existing employees to include references to the fad.  There could be room for debate on this one, but a short search on monster.com or dice.com show a plethora of ‘agile project manager’ versus ‘project manager’ positions.   Equally, we’ve seen software developers that specialize in agile practices now called “ninjas” and there is the  “agile scrum coach” that now replaces the old title “application development manager”.

5. Claims of a measurable business improvement via measurement of a metric that is defined by the fad itself.  Velocity is the most prominent measure that comes to mind.  Further velocity is defined in increments the fad defines: story points.

6. An internal sponsoring department or individual that gains influence due to the fad’s implementation.  Organizational Agile Coaches, or an Agile Center of Excellence are two examples that have become common.

7.  Big words and complex phrases.  This one is kind of subjective, but YAGNI might quality. SolutionsIQ even published an agile glossary so you can keep up with all the terms & definitions.

Fad? Yes.  Value?  Yes.

So by this definition agile is, well,…a fad.   But does that mean agile practices have no value?  Here’s some of the things we’ve learned ( or re-learned ) from agility:

1.  Daily communication among team members really matters when the work is complex.

2.  The people doing the work must be accountable for it.  Don’t let them hide behind a project manager.  Let them take pride in what they do.

3.  Requirements require constant communication, clarification and understanding.  It’s a continuous phase communication cycle, not a document.

4.  Regular, timely feedback on work improves quality and job satisfaction.

5.  Teams need help coordinating, facilitating and communicating between themselves and others.

Agile’s popularity is still growing.  Clearly some of us see benefit even as the marketing machine twists agility into something it never really was or will ever be.  Like management fads before it ( Six Sigma, TQM, and CMMI ) agile has made an impact on how we create value.

Is there a cult following?  Of course.  Everyone likes being popular and making money.  But the end state of the agile bubble will be a reconciliation back to reality.  There’s no silver bullet.  Problems still exist and we’re never fast or perfect enough for the shareholders or customers.  Room for improvement is omnipresent.

Summary

The fever pitch of the fad is a beacon.  Full value has been realized, copied, marketed and redistributed without concern for the result.  While time exists and there is still competitive advantage…the crowd still gathers.  But, the drivers of innovation have long moved off the curve of agility, hybridizing and envisioning new methods and tools for further improvement.  Another wave will again crest and break onto the shores of software management and leadership bringing the promise of ultimate productivity and quality, but delivering only incremental improvement.

Iterations Are to IT What Containers Were To Shipping

Introduction

Container shipping transformed the way goods were transported across geography and channel.   Instead of having many diverse payloads in differing container configurations for different modes of transport; a standard was defined for a rectangular container that could, through a set of standardized connection points,  be bolted to ship, train, or truck.   The result of simplifying the container configuration meant that transferring cargo between modes of transport became easier, shipping times were reduced from port, to rail, to truck.  Handling and management costs also went down because there was less variation in the cargo.

In the same way agile is standardizing the time-boxed delivery mechanism for software development.  Widely, today, the iteration is seen as that container.  In the majority of agile shops the 2 week iteration with a daily stand-up, front end planning session, and back-end review session; is the norm.  The channel of delivery might be scrum, xp, lean/kanban, or some hybrid of these.  The choice of which channel to use is deeply dependent on the business environment surrounding the software shop.   But regardless of the rails the iteration rolls over; it has become the choice for time-packaging completed requirements.

What are the implications of this to business and development groups?  What changes does this standard for team delivery impose/challenge the modern organization with?

Finance and Accounting

How capital projects are financed for internally used software has not followed the train of direction the iteration has brought forth.  Traditionally, project estimation is bottom up and we derive funding by establishing a level of effort ( LOE ) across the project, with some breakdown into work packages.    Iterations have the capacity to be the bricks of capital financing upon which projects are funded.

The challenge to IT finance groups is to derive the cost accounting for an iteration ( essentially a two week productive work team ) and then establish capital planning policies and procedures that estimate, plan, track and account by those iterations.

At first blush this sounds simple.  Why not just figure out the appropriate team composition: say 3 developers, 2 qa folks, 1 product owner and 1 team leader.   7 people X 50 hours a week = 350 hours X $70.00 per hour = $24,500.00 per iteration.  So now we just need to figure out how many iterations we need.  Right?

But wait….

What if I need a DBA, Infrastructure Person, or support analyst engaged?  How about software licensing, pc costs,  PTO ( paid time off ), employee rates vs consulting rates,  and other indirect costs?   What about the funding mix for any iteration?  Surely not all of it is CAPEX.  Some of it may be OPEX.  But what mix of a typical iteration should be OPEX vs CAPEX?   Should certain iteration models exist depending on what the team is doing?

These questions begin to explode the subtlety.  By standardizing delivery on iterations, the finance group and IT leadership can standardize the IT shop and its costs.  Should success be achieved, CAPEX and OPEX planning should become less complex and more routine; fundamentally reducing the infrastructure, roles, and process associated with this annual event while simultaneously establishing a standardized point of accountability and process planning.

This also changes the very nature of estimation from detailed to relative.  We’re now looking at value creation, rather than cost control.  The challenge back to the business will be how much value is derived at various cost points and at what point cost becomes too much.   Project costing becomes a negotiation toward shared value based on relative targets achieving a defined set of NPVs.

Management and Leadership

In an iterative organization the control, power, and operation are at the iteration team level.  Influencing those groups will require a leadership and management structure that is comfortable with fluid and mobile adaptation of resources to project needs.  Leadership truly begins to shine in this type of paradigm.  No longer dependent on a static formal organizational structure to derive power, the real leaders will begin to exert influence over these mobile iterative pods.

Those succeeding in such an organization will be gifted in the art of servant leadership, coaching, influence, and mentorship.  Command and control will be reserved for extreme HR issues alone.

Innovation

Iterations also change the shape of R&D and new innovative initiatives.  Iterations demand transparency, accountability, and risk reconciliation.  The iteration opens things up and standardizes the cycle of delivery.  To many this may stifle the idea of invention and creation by putting it on a disciplined cycle, but does it?   In plain english: business demands a return on its investment.  Research for research sake is a university concept.

Org Charts & Structure

How is organizational structure affected by the expansion of iterations?  While most IT shops today are familiar with the matrixed organizational structure, the iterative organizational structure groups teams into standardized pods for delivery.

The pods would favor generalists who are good at a multitude of IT functions but perhaps are not perfect at all aspects.  This structure would be fluid and adapt to organizational need.  An example iterative structure is below.  In this way the iterative POD is responsible to the director as a team.  All individuals in those pods report to him/her.

Personal Career Growth and Development

Iterations have already had an enormous influence on personal career development at software shops.  It’s not enough to be just a code whiz. Iterations place emphasis on teamwork, personal accountability, and decent communication skills.  Flexibility is also a key aptitude sought in the iterative individual.

Good delivery PODs are ready made hired guns.  Teams of professionals that could potentially write their own engagement.  In this way staffing by placement firms and consulting groups changes from individual placement to team sourcing.

Summary

The transformation of the shipping and distribution industries to containers wasn’t a simple overnight change.  Standardization requires upheaval and new ways of thinking, approaching old problems.  Organizations that adapt to the standard IT container and see it as more than just a ‘development thing’ are best positioned to yield the benefits that this change could bring.

A Caboodle of Pragilematic Posts

I’ve been hanging out and posting at the ASPE SDLC blog.  Yes…I have their permission to do that.  Geesh.  Check em out Gilbert:

Six Things To Avoid When Reporting Project Status – Project status is about the facts and your strategy to address and manage those facts.

This Daily Standup Is a Joke – This article details some challenges associated with daily stand-ups and some potential strategies for dealing with these.

An Axiom of Project Success –  What’s the common thread to project success?  We’ve seen projects that should have died.  We’ve also seen projects fall apart that seemed like they were in the bag.  This post attempts to nail the overriding factor.

That’s Great…But How Does Agile Benefit Our Shareholders?  – Selling agile to key leaders in your organization takes more than just a thorough understanding of story points, and time-boxing.  This post brings it home for those wanting  a bigger bang for their agile swang.  Whatever that means.

KTTW

Productivity can get lost in the haze of doing.  We often mistake the furious completion of many tasks in short order as an example of accomplishment.  Proudly, we mark it ‘done’ and then triumph in our ability to execute so well.

But productivity that counts means getting key things done effectively.  Always striving after the low hanging fruit yields many trees in need of further, incomplete harvest.

Agile rekindled the power of the time-boxed effort for teams.  Through an iteration we discover a game of sorts, an artificial finish line.  By the team committing to some set of work within that iteration there’s a bond of ownership and determination to complete.

While agile does this on a team level, the application is just as effective on a personal productivity level.  KTTW ( Key Things This Week ) is an example of this.

How does it work?

Friday Before You Leave Work:

Make a list of the key things you need to complete next week.  You define ‘key things’ by answering these questions:

  1. By completing this task this week will I move my project, team, company forward significantly?  Will it make a difference?
  2. If I don’t complete this task next week what’s the worst that would happen?
  3. Will completing this task move me closer to success?

Key things should answer yes to question number 1.  Each key thing should move your project, your life, or your company forward in some significant way.  I’m not suggesting you should complete a 6 month project in a week, but the question focuses you on what will make a difference versus what’s just keeping you floating along.

Question two validates in the opposite way.  If you never actually complete this task…what would happen?  Would you be let go?  If so…better do it.  If it’s low value work that can get done later…then save it for when you’ve completed the key things for the week.  Then you can knock out a handful of these low hanging fruit, and you won’t feel like you’re avoiding the 1000 pound white shark  in the room.

In the last question you define success.  Notice, I’m not asking if it gets you closer to done.  Who cares if you’re done. Lots of people get ‘done’, but how successful is their completion?  What matters is success.  Here’s where being effective comes in to play.  It’s not about just being efficient, it’s about getting the right things done to achieve success.  Your answer to this question should be ‘yes’ if it’s a key thing.

When you start up work on Monday…. break out your list and start tackling your KTTWs.  Your commitment should be to getting this list done by Friday irrespective of your other work.   Commit to this no matter what. What order?  Doesn’t matter. How much time should you devote to each key thing? You decide. Should I use a tool to track them? If you want.

KTTW is a light, time-boxed personal productivity tool.  I’ve used it effectively for many years, and can attest to it’s power in consistently focusing my mind, and effort to what truly needs to be completed to achieve success while at the same time weeding out the nonsense which clutters my day.

 

Getting to Success Instead of Getting to Done

Projects are about getting things done…right?

Uh-Uh.

They’re unique, collaborative, human efforts endeavored to achieve success.  Success is can be defined with certain goals.  Success has a point, a place we reach and can say “Ah-ha!….we did it!”.   There’s a finish line.  Done, on the other hand, is never done.  Excuse the pun.  And the rhyme.

Done is an endless backlog.

Done is a never ending series of requests.

Done is code that’s never perfect.

Done is test cases that still need to be refined.

The fog of “Done” can envelop the project and the minds of our teams.  It obscures the truth.  We’re not looking to get everything “done”.  We’re looking to succeed.  Within success there is room for variation on “done”.

The Root Cause of Water-Scrum-Fall

Introduction

Water-Scrum-Fall is the norm in many organizations today.  Despite the attempts of scrum coaches and consultants, the weeds of waterfall grow back into the agile garden.  What causes this?  This article looks at the root cause for the water-scrum-fall phenomenon and makes a suggestion about how to address it.

The Root Cause

Water-scrum-fall’s reality is not the result of people being unwilling to adopt scrum.  It’s not the result of a lack of passion for agile processes and practices.  Nor is it caused by a lack of executive support.  The cause?

Capital budgeting

In companies that produce software for internal use water-scrum-fall finds it’s greatest adoption.  Internally used software is strictly accounted for by the regulations in SOP98-1 and this financial machinery is what guides the need to plan up front.

Capital projects are investments.  To determine an investment’s return you need to know the estimated initial cost, and estimated revenue ( or savings ) the project will create.  These things are estimated up front so that a decision can be made on whether or not to pursue the investment.  The up-front nature of capital budgeting compliments waterfall and BDUF. It is a core financial business process guided and regulated by FASB.  Think about that for a moment…and then read on.

Scrum practitioners run up against a wall with capital budgeting.  It doesn’t fit their operational practice for developing software.  Under scrum….we shouldn’t be designing, estimating and crafting the project up front.  Instead we should approach it incrementally.  The problem with this? It ignores how enterprise software development projects ( capital investments  ) are funded.  The result is that everyone compromises and innovates.  Water-Scrum-Fall is the child of this compromise.

The Challenge

Scrum and other agile practices pose a challenge to enterprise software development efforts and the capital budgeting process.  Indirectly they say “Why are we funding this as a capital investment?  It’s not.  It’s an ongoing operational cost and should be accounted for that way.  If we don’t plan on funding this software development effort for the long haul…then why are we doing it?”  Funding a software development effort as an operational expense, as is done within software companies, does fit the scrum operational practice better.  But again…the difference between a software development effort being labeled CAPEX or OPEX is guided by FASB.  It’s not up to the company.

How Do We Fix Water-Scrum-Fall?

I don’t think there’s a silver bullet here.  But in my last article, Is There a Better Way to Estimate Capital Projects? , I threw out a suggestion for how to estimate a capital investment using tolerances.  This bypasses the need for an up-front detailed analysis of what the the LOE ( Level of Effort ) would be for the project, but still gets the business what it needs: an initial funding point and resulting NPV that augments decision making.

Summary

So water-scrum-fall is a pragmatic reaction by agilists and IT professionals to work with the business and its financial processes.  Did the originators of scrum not understand the capital budgeting process?  Were they oblivious to the financial architecture of the businesses around them?  Maybe…but to their credit; they weren’t trying to address this.  Their focus was on how to do software in an adaptive fashion so that it more organically addressed the operational realities of manifesting a complex vision.

Is There a Better Way to Estimate Capital Projects?

Introduction

“I don’t understand why you keep asking us to estimate the work. With all the time we’ve spent estimating we probably could have completed the first few requirements already. This is a waste of time!!” Ever heard something like this before? It comes across a little naive with regard to capital budgeting.  But there’s a good point in the vehemence…. Waste.

In this article we’ll rethink estimation.  We’re going to look at the machinery above estimation that catalyzes the need to predict effort and then propose a different way to target capital funding for projects.

Backgrounder

I don’t want to lose anyone here so I’m going to go over some basics of capital budgeting for internal use software projects and how that relates to estimating.  If you know SOP98-1 already then skip to the next section. Estimating can seem like a game.  At best it’s an educated attempt to predict the future using formulas and experience.  At worst its a W.A.G.  So why do we do it?  It all starts with how we account for the expense of developing internal use software. Internally used software is classified, for accounting purposes, as a fixed, long term asset.  In accounting speak: a capital expense.  That means it can be purchased for a set price and has a useful life greater than 2 years.  Capital expenses, like internally used software, can have their cost depreciated ( amortized ) over the useful life of the asset.  What does that mean?  It means that instead of realizing the entire cost of the custom software effort in one year…..you realize it over the useful life of the asset.  So if we intended some custom built workflow system to last 5 years and the entire cost of the initial development effort was $312,333.04 then we’d ( in a simplistic amortization schedule ) realize, report $62,466.61 in expenses per year for 5 years on each annual income statement.  Further the software’s depreciated cost would be listed as an asset on the corporate balance sheet each year until the full value had be amortized. The ying to the capital expenditure yang is the operating expenditure.  Operating expenditures are incurred, realized as they are spent.  There is no depreciation of cost.  If I have $125,000.00 in operating expenditures this year then $125,000 in expenses shows up in the income statement.  Operating expenditures are not considered assets and companies routinely seek to minimize their cost and flatten their growth.  How do they do this? Well….one way is by investing in capital assets that can help increase productivity.  So if I invest in some custom workflow system that will reduce the number of FTEs ( full time employees ) I need by 10% then that’s a potential long term realized gain in operating expense reduction: a.k.a. more profit for shareholders. Capital expense accounting can seem like magic if you’ve never heard of it before.  But there’s a very real justification behind it. What is that?  Simply put: if you’re capital asset increases profits each year after it’s implemented then those profits should be offset each year by the cost to develop that asset. Fundamentally, capitalization of IT expenses is an immense part of why companies invest so much in new technology.  The accounting allows us to derive value from capital investments.  Yes, technology is wonderful, but if internally used software expenses weren’t capitalized you’d see IT budgets shrink drastically.

Estimating

Awesome.  So how does this relate to estimating the effort on a software project.  Remember this line from above: That means it can be purchased for a set price and has a useful life greater than 2 years?  A capital project is an investment or a series of investments.  Knowing the price up front each year creates two things:

  • The funds needed to purchase that investment.
  • The cost basis to use in constructing a model of investment return.

Each of these capital investments are compared against each other using a % return ( IRR ) or more commonly using NPV ( Net Present Value ).  Some are required and ‘must be done’.  But the rest are optional.  So leadership uses the projected investment return to determine which ones will benefit the company most.  That becomes a short list of capital projects to fund for the fiscal year. Now, when these projects are initially compared developers may have been involved in the estimation process or they may not have been.  But regardless the estimate is usually classified as a ROM ( Rough Order of Magnitude ).  Once the project is funded another round of more detailed estimating occurs with the development team for the strict purpose of validating the ROM.  If our detailed estimation shows we have inadequate funds then we need to make a decision:  cancel the project or increase the investment.  But if we increase the investment…how does that affect our return?  Should we do a different project instead?  You see where it’s going.   Estimation is a fundamental part of determining the capital project landscape.  It’s the basis for determining the initial and subsequent investment to achieve an estimated return.  Software is just a means to the real end: increasing organizational productivity.

Capital Budgeting Hasn’t Kept up With Agile Practices 

The astute among you will recognize how this financial model of capital budgeting doesn’t fit what you’re actually doing in agile software development.  Big shock…right?  Agile techniques are operational practices.  They aren’t financial, business practices.  Estimating each iteration using planning poker or whatever method has no applicability or affect on the overall investment.  Just because the development team boosted the number of story points in the release…doesn’t mean someone magically added more money.  Capital budgeting doesn’t take place every 2 weeks.  It’s usually an annual event in corporations, although some companies will extend their capital planning for longer horizons ( 2 or 3 years ).  Accounting is the architectural tool that builds business models.  It runs in annual and quarterly cycles.

But It’s Wasteful

Ok, so back to the top.  It may be fundamental to determining the annual capital project garden for XYZ Inc., but the estimates are usually inaccurate and they waste precious time in construction.  Regardless of method…capital projects rarely hit their exact mark.  This pushes many companies to see IT as a money pit to minimize.  Isn’t there a better way for determining our cost basis for capital projects?  Maybe one that doesn’t require us to estimate anything? Everything about capital budgeting is hard to change because it isn’t up to the company.  It’s regulated by FASB.  They define all these rules, and help to police them.  The government recognizes FASB’s standards in lawsuits and for that reason they have the affect of law.   Creative experimentation with accounting standards inside companies is something that people go to jail for. So change in accounting practices and standards is slow and carefully considered.  After all you’re monkeying with the monetary machinery of global industry.  There had better be a good reason for any change. So the next section proposes an idea for change to FASB’s capital budgeting rules.  Do NOT exercise this idea in your company.  There is no provision for this idea in FASB’s standards to my knowledge.  I offer it up simply for conversation and debate….not actual practice.

Relative Targets

When we’re looking at capital projects we need to know the expected revenue ( or savings ) generated by the project after completion and the expenses ( investment ).  Estimating, at least in IT land, deals mostly with the expense side. This is usually done in a very detailed fashion, but with relative targets I’m proposing we skip the estimation and just come up with a tolerance level.  How does it work?

1. Determine your expected revenues ( or savings ) if the project is implemented.

2. Determine your return thresholds.  There should be three.  You could do this with NPV or IRR.

  • The return you’d ideally like to get.
  • The worst return you’d tolerate ( yes it can be negative ).
  • The middle ground between these.

3.  Once you have these 3 thresholds you can then back calculate the capital requirements necessary to fulfill these return levels.  We’ll work through an example in a moment.  But here is the formula we’d use:

Formula to calculate investment for targeted NPV

C = NPV – R / ( 1 + r )

where

  • NPV = Targeted NPV
  • C = Investment required to reach targeted NPV
  • R = Revenue realized in each period
  • r = discount rate

4. Next you’d do a gut check.  Can we really do this project for anyone of the calculated capital thresholds identified?  If we can’t…then we shelve the project.  If we can then we would setup 3 tranches of capital per project correlating to the thresholds.  You’d start off by shooting for the ideal return scenario.  If that didn’t work…you’d make a decision to move on to the middle ground threshold or cancel the project and expense the loss.  The same would occur for the worst case return.

Example

So let’s say we have a project that we know will generate the following savings in years 1, 2 and 3.  Year 0 is our capital investment and what we’re trying to solve for.

Year             Cash Flow
0                 $???,???
1                  $200,000
2                  $300,000
3                  $200,000

Ok, so we know our estimated benefits from doing this project.  Now we need to figure our our three thresholds for year 0 capital funding.   Ideally we want to maximize our benefit.  So let’s say in consultation with the business we determine that these are our NPV thresholds:

  • The return you’d ideally like to get:  The most ideal return would be one that requires no investment at all and we receive the present value of the expected benefits – $580,015.02.  But this is unrealistic.  It does, however, give us an upper boundary to our ideal return.  So we’ll say that a more realistic ideal scenario is $400,000.00 in NPV.
  • The worst return you’d tolerate:  This could be negative.  Maybe you’re willing to lose money to get this software project completed. Good examples would be where there is a regulatory requirement associated with completing the project.  In this example we’ll say that the worst return we’re willing to tolerate is $100.000.00.  This is above zero, but shows that we’re looking for some monetary benefit.
  • The middle ground between these: I’ll just take the average between these two…..$250,000.00.

Great…now we just plug these values back into our formula to derive the initial maximum investment allowed to hit each threshold. We’ll use 10% as our discount rate.

Ideal Investment:

$400,000 – ($200,000/(1.10 )  + $300,000/(1.10²) + $200,000/(1.10³)) = -$180,015.02

This says that the most ideal return would require for our investment to not exceed $180,015.02.

Worst Case

$100,000 – ($200,000/(1.10 )  + $300,000/(1.10²) + $200,000/(1.10³)) = -$480,015.02.

This says that to achieve the worst investment return tolerable the investment must not exceed $480,015.02.

Middle Ground:

$250,000 – ($200,000/(1.10 )  + $300,000/(1.10²) + $200,000/(1.10³)) = -$330,015.02

Here we believe that to get a return of $250,000 we’ll need to make sure our investment does not exceed $330,015.02.

Now that we have our tolerances we can do a gut check and see how realistic it is to complete the project based on each level of funding:  $180,015.02, $330,015.02, and $480,015.02….or anywhere between them.

If our gut check tells us we can complete this project then we’d fund the tranches and start on the project.  If not then we’d drop this project altogether.

Summary

Relative targets take us out of the game of detailed estimating and instead push us to delivery within some tolerances.  This is a more natural way to manage a risky endeavour and affords us some built in cushion that everyone agrees is acceptable to the business’ needs.  We also pre-build fault tolerances, trigger points that force us to reflect on the project’s viability.  Here I suggest that there should be three of these tolerances, but there’s nothing preventing a company from setting up 4,5, or 10.