Posts Tagged ‘productivity’

Multiple, Independent Sources Of Information On The Same Topic

July 3, 2014 1 comment

I can’t rave enough about how great a subscription is for writing code. Take a look at this screenshot:

Five Books Open

As you can hopefully make out, I have five Firefox tabs open to the following C++11 programming books:

  1. The C++ Programming Language, 4th Edition – Bjarne Stroustrup
  2. The C++ Standard Library: A Tutorial and Reference (2nd Edition) – Nicolai M. Josuttis
  3. C++ Primer Plus (6th Edition) – Stephen Prata
  4. C++ Primer (5th Edition) – Stanley B. Lippman, Josée Lajoie, Barbara E. Moo
  5. C++ Concurrency in Action: Practical Multithreading – Anthony Williams

A subscription is a bit pricey, but if you can afford it, I highly recommend buying one. You’ll not only write better code faster, you’ll amplify your learning experience by an order of magnitude from having the capability to effortlessly switch between multiple, independent sources of information on the same topic. W00t!

The Drooping Progress Syndrome

September 21, 2013 Leave a comment

When a new product development project kicks off, nobody knows squat and there’s a lot of fumbling going on before real progress starts to accrue. As the hardware and software environment is stitched into place and initial requirements/designs get fleshed out, productivity slowly but surely rises. At some point, productivity (“velocity” in agile-ese) hits a maximum and then flattens into a zero slope, team-specific, cadence for the duration. Thus, one could be led to believe that a generic team productivity/progress curve would look something like this:

steady increaseIn “The Year Without Pants“, Scott Berkun destroys this illusion by articulating an astute, experiential, observation:

This means that at the end of any project, you’re left with a pile of things no one wants to do and are the hardest to do (or, worse, no one is quite sure how to do them). It should never be a surprise that progress seems to slow as the finish line approaches, even if everyone is working just as hard as they were before. – Scott Berkun

Scott may have forgotten one class of thing that BD00 has experienced over his long and un-illustrious career – things that need to get done but aren’t even in the work backlog when deployment time rolls in. You know, those tasks that suddenly “pop up” out of nowhere (BD00 inappropriately calls them “WTF!” tasks).

pop up task

Nevertheless, a more realistic productivity curve most likely looks like this:

decreasing productivity

If you’re continuously flummoxed by delayed deployments, then you may have just discovered why.

productivity cycle

An Estimation Example

October 17, 2010 Leave a comment

The figure below shows the derivation of an estimate of work in staff-hours to design/develop/test a Computer Software Configuration Item (CSCI) named YYYY. The estimate is based on the size of an  existing CSCI named XXXX and the productivity numbers assigned to the “Real Time” category of software from the productivity chart in Steve McConnell‘s “Software Estimation: Demystifying the Black Art“.

Of course, the simple equation used to compute effort and all of the variables in it can be challenged, but would it improve the accuracy of the range of estimates?

Add Managers And Hope

September 2, 2010 Leave a comment

The figure below shows the result of two attempts to increase the productivity of a hypothetical DICteam. In this totally concocted and fictional example, the nervous dudes in the penthouse (not shown in the figure) keep adding specialized managers to the team to fill voids that they perceive are keeping performance from improving. However, since the SCOLs never baseline the TEAM_VALUE_ADDED metric before each brilliant move, or track its increase or decrease with time, they have no idea whether they have achieved their goal. Because SCOLsters think they’re infallible, they just auto-assume that their brilliant moves work out as expected.

Of course, it often turns out that SCOLster decisions and actions do more harm than good. As the graph in the figure for this bogus example shows, not only did the team operating cost increase by the addition of two new manager salaries to the total, the team productivity decreased because of the additional communication and coordination delays inserted into the system. Add an additional “hidden” operating cost due to the high likelihood of jockeying and infighting between the three BMs (to gain favor from the penthouse dudes), and the system performance deteriorates further. Bummer.

So how can SCOLs increase team performance without throwing more useless overhead BM bodies at the problem? For starters, they can clearly communicate the gaps they “see” to the single team coordinator and help him/her rise to the challenge by providing mentorship and advice. They also can replace the BM with a competent, non-BM (fat chance). They can also (heaven forbid) invest in better tools, infrastructure, and training for the one coordinator and team of DICmates – instead of investing that money in more BM specialists. Got any more performance increasing alternatives to the standard “add managers and hope” tactic?

Esther Tweets

August 31, 2010 Leave a comment

I’m passionate about all aspects of software development, including, uh, project management (I really am). Since Esther Derby is an insightful and pragmatic thinker filled with valuable tips, techniques, and methods for successfully executing hairball software projects, I follow her on Twitter. Check out this trio of sequential tweets.

My answer to Esther’s last question is: “It would be great!“. Alas, most managers don’t, or aren’t allowed to, think in terms of systems. Systems thinking isn’t valued in siloed, CCH corpricracies, so managers have no incentive to learn or apply it’s principles and techniques for continuous improvement. In really badly run orgs, it’s too dangerous for one’s career to think or act horizontally in silo-city. It’s too bad, because orgs of people are richly interactive dynamic systems of systems that require constant shepherding to keep every person and every group and every unit aligned and connected.

What Happened To Ross?

September 4, 2009 Leave a comment

In the ideal case, an effectively led company increases both revenues and profits as it grows. The acquisition of business opportunities grows the revenues, and the execution of the acquired business grows the profits. It is as simple as that (I think?).

ROS (Return On Sales) is a common measure of profitability. It’s the amount of profit (or loss) that remains when the cost to execute some acquired business is subtracted from the revenue generated by the business. ROS is expressed as a percentage of revenue and the change in ROS over time is one indicator of a company’s efficiency.

The figure below shows the financial performance of a hypothetical company over a 10 year time frame. In this example, revenues grew 100% each year and the ROS was skillfully maintained at 50% throughout the 10 year period of performance. Steady maintenance of the ROS is “skillful” because as a company grows, more cost-incurring bureaucrats and narrow-skilled specialists tend to get added to manage the growing revenue stream (or to build self-serving empires of importance that take more from the org than they contribute?).

Constant ROS

For comparison, the figure below shows the performance of a poorly led company over a 10 year operating period. In this case the company started out with a stellar 50% ROS, but it deteriorated by 10% each subsequent year. Bummer.

Deteriorating ROS

So, what happened to ROS? Who was asleep at the wheel? Uh, the executive leadership of course. Execution performance suffered for one or (more likely) many reasons. No, or ineffective, actions like:

  • failing to continuously train the workforce to keep them current and to teach them how to be more productive,
  • remaining stationary and inactive when development and production workers communicated ground-zero execution problems,
  • standing on the sidelines as newly added “important ” bureaucrats and managers piled on more and more rules, procedures, and process constraints (of dubious added-value) in order to maintain an illusion of control,
  • hiring more and more narrow and vertically skilled specialists that increased the bucket brigade delays between transforming raw inputs into value-added outputs,

may have been the cause for the poor performance. Then again, maybe not. What other and different reasons can you conjure up for explaining the poor execution performance of the company?

Productivity Lag II

In part I, we saw that the learning curve for each person is different (duhhh). I also defined the Critical Mass Time (CMT) to be the time lag between starting a new project and actually being able to “start contributing something useful”. The figure below recaps this idea.

productivity 1

Other factors, besides experience and expertise, that determine the CMT value are: the amount of, the quality of, and accessibilty of pre-existing information about the problem to be solved. If the information is sparse, fragmented, and/or inefficiently stored in other people’s fallible memories (tribal knowledge) because of the failure of management to lead, then the CMT will be larger than if  the critical-to-success information is coherent, integrated, and recorded somewhere that is easily navigable and accessible.

At the CMT point, productivity starts manifesting in the physical world as visible intermediate work outputs. Product specifications, designs, test definitions, equipment assembly, prototyping, model definitions, etc., begin to emerge and push the project forward. Like any activity that is predicated on fallible human thought, the creation process is iterative and chaotic. It is not smooth and organized as the final output may imply to an after-the-fact external observer (like most managers). It takes iterative, mistake-prone work and structure to temporarily harness the ever present increase in entropy.

The figure below shows the full time lag between project start and project completion. Again, the time lag ‘tween CMT and project “done” is highly person-specific.

One And Done

The figure below shows the end-to-end project start time to project done time for three different people that were given the same project task to perform. The difference between the total “schedule” performance of person 3 and person 2 is the case we want to zoom in on. How could it be that person 2 ramped up faster than person 3 but finished the project later? WTF?

Three And Done

Some reasons that may explain this anomaly are:

  • Person 3 had a hard time finding and absorbing high quality, pre-existing information about the project and task at hand.
  • Person 3 is slower at learning, but more talented at applying.
  • Person 2 lost some motivation for one or more reasons and slacked off somewhat
  • Person 3 rushed through the task and produced crappy output that may not be discovered until the project is further downstream; where the cause might not be connectable to the person’s output.

I’m sure that there are a gazillion other factors that may explain the anomaly. You can form your own list.

The main point of this article was to discuss what everyone knows, but often forgets: Numbers don’t always tell the truth. Superficially looking at hard and cold “schedule performance” numbers without digging in to examine their validity can be unfair to those who are quantitatively measured for personal performance evaluation by hierarchs. Lazy bozo managers who do this deserve what they get: the exodus of some of their best performers, an unmotivated workforce, a low quality product portfolio, and an unfair reward system. In essence, it’s one of the hallmark characteristics of the herd of mediocracies that cover the landscape of the business community.

%d bloggers like this: