Agile Portfolio Management

Agile portfolio management is the first level abstraction of Agile values and practices up into the business.


Note here that we will be differentiating between agile and Agile. Specifically, agile refers to the ability to change and the ability to both manage and accept that change within operational activities. Agile refers to that family of methods and frameworks characterized by light touch management, iterative development, and Justin time planning. Some examples of Agile are Scrum, Lean, and XP.


Portfolio Management is a fairly common business term and refers the process by which some one or some organization actively “manages” a group of independent “variables” to better achieve some pre-stated “objective”. A really good example of this is a stock portfolio. Many of us have excess wealth that we are putting away for a rainy day (read retirement). Much of this wealth has been secured in financial “tangibles” – or various stocks. Usually under the watchful eye of a financial analyst (be it our self, our spouse, our best friend, or a hired gun) this group of tangibles are selected purposefully to both diversify (stabilize) our portfolio and to help achieve its objectives. Clearly, the objective is to maximize value growth; however, that is the simplistic response because each of us has a different tolerance for risk and a different set of values.


Some of us, closer to retirement, may opt out of those speculative rocket type growth tangibles because we innately know that what goes up (really fast) may also come down really fast (how many of us did not buy Google at $250 for this reason?). This group has a more conservative set of objectives termed wealth protection – a growth rate of 3-6% to keep up with inflation is sufficient to keep financial smiles affixed here. Others of us believe we can call the system, we are younger and more able and willing to gamble big. This group might liquidate savings to jump into a speculative opportunity in order to achieve a great payoff (say, buying Google at $250 to sell at maybe $500?). At any rate, here you are – a bunch of people with portfolios that are managed towards some prestated objectives.


Usually, though not always, those that achieve their goals are helped by a professional portfolio manager. More often than not, the unsuccessful ones are those that think they can do well enough as a part time manager, while they focus on other things (life, job, whatever). Success here is hit and miss. Interestingly, I would term these (all of these) as agile portfolios, here is why:


Periodically, perhaps not regularly though, each portfolio is examined to determine if it is operating towards the achievement of the stated goals and objectives. In fact, each of the stated goals and objectives are examined periodically to make sure they have not changed either. Usually, if the portfolio is not managed by a professional, these review events are based upon external stimulus: 60th Birthday, Birth of a child, Surprise bankruptcy of one of the portfolio companies, overt irrational exuberance relating to one of the tangibles, and so on.


The agility of the management happens in that the portfolio owners chartered their portfolio when they started and in the process of reviewing the goals and objectives they are acknowledging change, embracing it, and using it to help direct their actions. There are no mandated plans here. The inability to change individual tangibles for others with different specific attributes is not a given, but controlled only by the inability to get someone to accept your price for them in a transaction.


In Agile, we try to govern our projects using a set of values. The default values are

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

These have wide applicability – we can even apply them to our financial portfolio:

• Listen to the current needs and desires of the owner of the tangible rather than being driven by their earlier stated plans. If they seem to be getting more conservative in their decisions, don’t program them into speculative buys.
• Hardly anyone who owns a portfolio of stocks reads all the filings and reports that are available. Mostly, even the professionals work from fused data and trends when directing activity.
• Clearly even professional managers are driven by their contracts and their contracts are usually written to protect them (limited or no liability for goal directed actions that tank completely), but successful managers get additional clients not through holding firm to the line, but by collaborating with their clients and seemingly understanding them, their risk tolerances. Successfully working with clients gets more clients – particularly if results are there too (but not, we said nothing here about successful achievement of goals).
• Google looks good to $400, not just $300, let’s stay in a little bit further, if you don’t mind…….

I see a lot of nodding heads. Everyone agrees, internal consistency, etc. So how do we apply this? First, let’s identify some takeaways I think we can all agree to:

1. These portfolios seem to generally do better with a professional manager than either a part-time or an amateur.
2. Periodic re-reviews of both the objectives of the portfolio and the performance of individual tangibles must be accomplished.
3. Professionals seem to manage portfolios better because they have less invested in individual decisions (I can’t sell this MCI, it will come back. I have to make back some of this loss!)
4. Too much tinkering in the portfolio can cause unnecessary thrashing and increase fees substantially

I am sure there are more, but let’s leave it here for now!

The world is a capricious place (part 1)

The world is a capricious place. Given the amount of moving parts – one wonders how it could be anything but. With the interests and desires of billions of people, the millions of companies they work for and the hundreds of countries they live within; it becomes relatively easy to understand the depths of the complexities, but far harder to understand the complexities themselves.

In the much smaller geo-corporate domain that is global IT, we are able to reduce the number of imperatives and variables several orders of magnitude; however vast amounts of the complexities still remain. Unadulterated successes continue to be such rarities that they are viewed as curiosities and so when we hear about them we tend to like to study them and understand why they were so successful.

Most of the time the analysis of these successful efforts, be they products or projects, points to successfully meeting expectations rather than completing requirements. This in itself is a very subtle point and is often missed in our line of work. Actually, who am I kidding, it is not often missed, but rather rarely realized – otherwise why would our successes be so rare.

Software development, the chief component – though in no ways the only component – of Global IT, started out as an art form. In the early days, examples of success were accompanied with associated tales of heroics from nearly super human programmers. The dramatic vagaries of the hit and miss nature of these efforts pushed the industry towards structure and rigor – establishing the discipline as a science that could be engineered. We invented frameworks and standards and eventually schemas to license practitioners. When this did not increase the probability of success substantially, we began to examine the differences between leadership and management. Unfortunately, like many business disciplines, we lost our way and focused on the precept that if we managed more strongly, we could manage out some of the degrees of freedom and improve the resulting probability of success.

Rather, what we accomplished was the introduction of regulation with the drive to reducing the statistical variation between what we asked for (including schedules and budget) and what we got. For a number of years, and an entire genre of literature, IT project management focused on how to encourage the teams to deliver what was asked for, when it was asked for, within the financial constraints required. It was here we coined the phrase “better, cheaper, faster!” It was also here where we discovered that in a highly regulated discipline, your IT organization could be considered no different than any other kind of factory with your staff viewed as interchangeable functional units, or “resources”.

Once we were of agreement here, the global economy kicked back in with a vengeance and we created a supply and demand based industry and the Outsourced IT model was born. But as Martin Fowler, a current day industry notable has been quoted: “I take the view that IT development is done pretty badly. If your communication is screwed up, then offshoring to India isn’t going to improve the situation. [But,] I suppose if you’re going to screw up anyway, you might as well pay less and screw up.” This is certainly not a complimentary view point and it is certainly not limited to India. You can substitute any country or culture you want. India isn’t even the most inexpensive outsource location anymore, though it is still the most common due to its vast number of highly trained individuals capable of working within the regimented frameworks we have invented to govern our attempts to force adherence upon our teams.

It is interesting to quote Martin here, as his punditing has, as of late, been focused around the Agile methods. These are still commonly viewed as ‘cowboy’ methods – unregulated, unreproduceable, and oft able to induce stampede behavior totally destroying not just the project they were working on, but the entire town through which they were riding. So why do we quote Martin? Because the agile methods focus principally on meeting expectations not completing specifications.

Holy Smokes, Batman - QA found a bug!

Even for those of you who did not grow up with the dynamic duo, the caped crusaders probably need no introduction. I am pretty certain that neither of them would ever actually write software in their crime fighting regalia; though I can certainly see them as part of an agile development team whilst in their street clothes!


Exploiting their personalities, they have an interesting dynamic and interplay that can help to underline the thoughts behind a common question in our space:

What do we do when QA (or anyone else for that matter) finds a defect?

In order to answer it, we will break it down into two parts and answer them separately:

1) What do we do when we find a defect with a work package during the iteration it was initially developed in?

Well, we would prefer to find all problems immediately, not solely because we want to move forward with maximum velocity, but also because as soon as the developers switch mental context to another work package, it is harder for them to resolve the issue. So, the recommended approach is to follow these steps:

a) Have QA develop acceptance criteria with the Customer prior to development starts – this will ensure the developers know what it means to be “done”.
b) Have the Customer review and validate the solution prior to verification testing – this tends to maximize throughput of the system, as long as this review is kept informal.
c) Once the solution is validated, QA will verify that it meets the acceptance test in a formal build (say, after the next cycle of Cruise Control).
d) If the solution can not be verified, the changes made are still very much in the team’s mind and finding the resolution will be most expeditious. No defect needs to be raised, unless the team is tracking metrics at such a level that these details are pertinent (CMMI level 4 and 5 organizations only).
e) Once the resolution is found, as long as the solution has not changed substantially from the original validation review, then it can be re-integrated and re-verified.
f) Receiving a clean bill of health from QA allows the team member to move on to a new story with no hangover and a clear conscience.


2) What do we do when we find a defect with a work package after the end of the iteration it was developed in?

Sometimes, defects show up well after the initial integration has been completed. Commonly, these are associated with architectural issues or defects with previous acceptance criteria. Regardless, though they can be trivial (typos or unsafe internationalization), more often they are reasonable arduous to resolve. Either way, the accepted procedure is:

a) Once found, raise a defect in the tracking system and request the Customer prioritize the resolution
b) If the priority is Immediate, then the issue should be assigned to someone to assess the scope of the resolution.

• If it is small, the fix should be made and the integration re-verified.
• If it is large, the Customer should be asked to confirm that the resolution takes precedence over planned work.
• A yes here initiates a change in the Iteration plan: an equal number of points are taken out of the iteration and this new work is substituted.
• A no puts the resolution into the backlog as a new story.
  

c) If the priority is not immediate, then the resolution is posted as a new story in the backlog and assessed once the Customer decided to play that story card (this could be in the next iteration or one way down the line, there are no rules here!).

In both scenarios, it is assumed that the team follows the agreed upon workflow for defects in the tracking system. We enter them into the system specifically so that we can capture as much context as possible while the issue is current in our minds just in case it is determined that we will not address it for some time. Logging of the issue and the failure modes will give those tasked with resolution background upon which to build a new context so that they can address and correct the issue.

The real key is to always evaluate the work through its value proposition to the Customer. They may be bothered by undesirable formatting of text in an automated report, but there may never be enough value to the company to have the team change it. On the other hand, if QA finds that through some quirk of the database manipulation, the system is arbitrarily over-writing data, it could be anticipated that an immediate correction must be made.

for now

With moving my infrastructure to the powerMac and the new Blogspot Beta not supporting the Mac yet, I am going to continue my blog through my employer's blog: www.vasoftware.com/blog.

Look for my latest longwinded rambling there!

cheers

Estimating Tasks

It is even more interesting that the spread sheet he (my builder) was talking about was his estimation spreadsheet. By adjusting several parameters, notably foundation size, room types and quantities, square footage, and some more – he felt comfortable that he had sufficient accuracy to cost the job, and stick to it! It was pretty simple and he confided in me that every so often he adjusts things in the spread sheet, but overall it is sufficiently accurate that he never messes up too badly. We talked about that a bunch. Once he was done with his line item estimates, he adds two additional categories – contingency and profit. Between the two, he has never lost money. He did indicate that on occasion he doesn’t make money, but he has never stiffed a sub nor failed to pay a bill. He has been stiffed by a customer.

[another aside for another post: While he was building our house, he was building a larger house on a more complicated lot. That owner was a PMP, I met him at a benefit for the Boys and Girls club, a hazard of using this builder. He had instituted a formal change management process with the builder so that both costs and changes would be managed completely. His wife was to be the arbiter and inspected the job site daily (or there abouts). We chose a more agile approach (surprise!). We were in our house 30 days late, but within our budget. They are 90 days late and counting and are 25% over budget and growing. However, they will probably have cable before us.]

The spreadsheet was used for the bank – to tell them why monies needed to be drawn down and what inspections needed to be completed in order to prove completion of rewardable milestones. The key to the spreadsheet was its heuristics that were developed over 20 years of building in the same towns with ostensibly the same vendors and subs. Much of the statistical variation had been eliminated, but there were still risks. No one could have anticipated that the hurricane would increase fuel so dramatically in turn increasing costs of things like bricks and plastic, nor the run up on copper that resulted from completely different reasons.
Now, if we could estimate our tasks with a spreadsheet, maybe we would eliminate the statistical variation as well. But wait! The variation on the house had to do with the weather and world events, not design. Our mason had built enough chimneys to know that a two story rumsford with strong detailing would take X days + Y depending upon whether it was too cold for the mortar to set. He reviewed the design, estimated the materials, and put in a bid. He ate a little of the bid because it turned out the foundation was mispoured and some augmentation was necessary (an extra day or so). The foundation contractor split the cost, we saw none of this.

So, what is the difference between the chimney and estimating and executing against a software story? Well, let’s think…In both cases, you want the final acceptance test to be a mere validation. It is really expensive to pull down a chimney and redo it if it doesn’t draw properly, just like throwing out an entire function and re-implementing is not cost neutral either, so that is not it. In both cases, customer expectations must be taken into consideration. In the masonry, there are fewer external interfaces, but there are some very basic ones (the foundation). Perhaps the biggest difference is that in software there are multiple ways of creating the logic tree that would carry the instruction flow - more than one way to skin the proverbial cat.

In masonry, there are many patterns to laying the stone or the brick, but each is an embellishment upon the basic plan. In software, there are innumerable paths that the logic can be defined to accomplish the task. The complexity becomes massively greater when dealing with an existing system because of the number of additional interfaces that must be managed and decision paths that must be integrated.

In agile, we try to break stories down to their elemental functions and then build them up including only those blocks necessary to produce a sufficiently strong structure. Unless specifically included in the story, all embellishment is extracted. The initial implementation should clearly be functional, but remain basic. This concept, YAGNI*, helps create a set of estimate-able tasks. What allows these estimates to become more accurate is the power of the group.



*YAGNI – You Ain’t Gonna Need It!

Nate Estimation

Well if innate estimation is what you do subconsciously, what do you do to estimate consciously? Hmm, well, let’s think. To estimate a task well is to consider how long it would take to complete satisfactorily: Mom said I can’t come out and play until my room is cleaned up. Well, how long will that take? Um, 5 minutes I guess.

Yeah, to who’s standard? Mom probably didn’t ask you to clean up your room cause it needs a mere surface cleaning and I assume you are not going to use heavy equipment, so your estimate probably does not take into account your customer’s standard of cleanliness.
So how long will it really take? There are two ways to define the effort for this task – first, set a timebox and clean as much as you can across that timebox. Your customer will probably accept this if a) the timebox is large enough to allow sufficient action and b) you work diligently across the entire timebox. The second way would be to sit down and understand what your customer’s expectations are and then examine the work from a task basis: 8 minutes to pick up dirty clothes, 12 to put the toys away and shelve the books, 10 to straighten and dust the furniture. There are no real uneventualities that may crop up to cause the estimates to be invalid; except perhaps if the monsters under the bed come out and start gnawing at your ankles while you work.

In most knowledge work, there are more unknowns that may complicate the task. But mostly, you are looking for tasks that may have some statistical variation to their completion. This is where the true joy of estimation really comes to fruition - another thing I learned building the house (truthfully, this I knew from 15 years ago during the early days of the CMM. Back then, we looked at other engineering disciplines like civil engineering to begin understanding why our software development processes were unable to establish some rigor about our work. My builder has been building for 20 years). As a funny aside, he is a good acquaintance of ours – he and my wife are both quite active in Rotary and the Boys and Girls Club in our area. He finds the frequency that I change employers some what interesting, since he has been self employed his entire life. So, as we were working on the house, he wanted to know about my current employer (Borland). Initially, the name meant nothing to him, as I expected, but then a spark lit up and he said “Visicalc! – that was my first spreadsheet!”

Innate Estimation

When we consider how long something is going to take us, we estimate it. Many times it is purely subconscious, but if you stop and think about it, we all do it all the time:

The light is yellow, let me see, do I have time to get through it before it is completely red?

I gotta pick up Maggie from school at 3. I can be 5-10 minutes late and she won’t be too grumpy, but more than that and it will be apocalyptic. If there is no line at the drive-thru, I can manage stopping at the Bank on the way.

I told them this morning that I would have this task done. It isn’t all that hard and I still have all afternoon. I don’t actually need to be out of here until 6 tonight, so, yeah, I can do lunch in the city.

When we estimate, do we actually consider potential interruptions? Now a day, no one stops their car to answer their cell phone, whether they should or not; so incoming calls do not impact arrival times unless they are directly associated with safety; however, incoming calls while you are working on an assignment do delay – Driving is a tactile activity that though we shouldn’t, we can successfully complete it at a more subconscious level. (Have you ever pulled into your driveway from a particularly harrowing day and realized that you don’t remember any facet of the commute?) Development work is knowledge work and though the brain is the best multi-processor ever, it is best at multi-processing subconscious and below. Once tasks need the actual conscious power of the brain, you gotta really concentrate (always check your oxygen levels!). I can walk, and talk, and chew gum, but I have never learned to play the piano with two hands – I can’t even multi-task a melody and a harmony in a seamless fashion!

When we estimate tasks, we naturally take many things into consideration. We look at various scenarios. Above, in my three examples, the first and the third address happy path because those are the ones I find more personally satisfactory: I don’t want to wait another light cycle; I want to do lunch with Ellen. The second addresses the non-happy path; but if you really look at it, the personal happy path is I can get my bank errand done and only inconvenience Maggie a little – so I will risk a sad path for her to give myself a happier path!