Communication pragmatics

A recent book review on the pragmatics of communication highlighted three ideas I'd not thought a lot about, but perhaps I should:

In the presence of another person, it is impossible not to communicate: This point is so obvious as to often be overlooked: silence amounts to communicating that one does not want to communicate. [Think about this as you contemplate virtual situations ... communications may not survive all that well]

Every communication has two aspects to it: ..... what matters is not only what is said, but how it is said and the context in which it is said.

The relationship is defined by how participants perceive a sequence of exchanges: A dialogue consists of a sequence of exchanges between participants. However, the participants will punctuate the sequence differently [In other words, the value of communications is changeable by sequencing and cadence]

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

IT technology Top Ten

Michael Cooney has posted Gartner's Top Ten for IT technology:

The Top 10 Trends and their impact, briefly include:

1. The evolution of virtualization: ... virtualization will ultimately drive more companies to treat IT [more] like a business. [Perhaps, but virtualization will more likely continue to change our idea of borders and boundaries, making them more virtual than real]

2. Big data, patterns and analytics: Unstructured data will grow some 80% over the course of the next five years, creating a huge IT challenge.

3. Energy efficiency and monitoring: The power issue has moved up the food corporate food chain.... An average x86 server that is turned on, but idle, will draw upward of 65% of its nameplate wattage, for example. 

4. Context aware apps: ...  context-based computing will go beyond the business intelligence applications and truly make a unified communications environment possible .

5. Staff retention and retraining: Loyalty to one company is not a quality found in new workers.

6. Social networks:    Ignoring social networking is not an option

7. Consumerization: The key trend here is the fact that new application types will be developed to address mobile users but they won't be desktop replacement applications. 

8. Compute per square foot:  ... average server performance can move from today's paltry 7% to 12% average to 40% to 50%, yielding huge benefits in floor space and energy savings. 

9. Cloud computing ...the biggest benefits of cloud computing are built-in elasticity and scalability.

10. Fabrics: Gartner defines this infrastructure convergence as: The vertical integration of server, storage, and network systems and components ...

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

That velocity thing

Jim Highsmith, a guru in the agile space, has an interesting post on that velocity thing. Velocity, you will recall, is the agile name--originally an XP name--for the rate throughput can be delivered to customers, or, if not delivered to customers, the rate at which throughput--finished deliverables--can be queued for rollout according to some rollout strategy and workflow.

 

Now, the idea of throughput is not an agile thing, per se. Go back to the mid-1980s to Eliyahu Goldratt's Theory of Constraints (TOC). TOC is all about optimizing at the enterprise or project level  maximum throughput to customers. Velocity was not a Goldratt idea, but Eliyahu certainly focused on cadence, using the metaphor of the drum-buffer-rope.

 

Of course, project managers may know Goldratt for his theory of the "Critical Chain", a risk management strategy for insuring on-time delivery. Critical chain is an outgrowth of TOC, and it's Goldratt's idea of how to put some of his throughput management ideas into the body of knowledge for project management.

 

I digress--as often happens here at Musings--so back to Highsmith's lament: he says that having positioned velocity as a calibration metric on team performance, project managers should not then count on teams to achieve the predicted performance because a emphasis on performance may then trump quality, the ultimate goal of an agile project. Even the customer may become part of the problem. In his words:

 

• Velocity is increasingly being used as a productivity measure (not the capacity calibration measure that it was intended to be) that focuses too much attention on the volume of story points delivered.
• Focusing on volume detracts from the quality of the customer experience delivered and investing enough in the delivery engine (technical quality).
• Giving the product owner/manager complete priority control makes the problem worse—we have gone from customer focus to customer control that further skews the balance of investing in new features versus the delivery engine. 

Dean Leffingwell makes a similar point in his book "Agile Software Requirements: Lean requirements practices for teams, projects, and enterprises". He says that if the velocity metric is turned back on the team by managers, the team will do one of three things:

1. Practice continuous improvement to meet management objectives
2. Sacrifice quality in the name of speed, or
3. Sandbag estimates to create velocity buffers

Of course, my point is not to use the metric to amp up productivity, (that's Highsmith and Leffingwells's fear) but to use the metric as an expectation suitable for estimating. If you can't estimate, what's the point of the metric?

And, they've got a point about sacrificing velocity if quality is the ultimate driver. But that puts 'better' as the nemesis of 'good', and puts in question the real advantage of agile that, in my mind, is delivering best value (which could be different from best quality, though I've not thought that all the way through).

And, you ask, what's my idea of best value? Simply put:

 

• Best value is the most valuable outcomes achievable, as judged by the customer, for the investment available from the sponsor
• Best value is the most bang for the buck, a best compromise of scope and quality in context of fixed investment and a critical need date.

By the way, I'm all about throughput. You really can't do a decent job as a agile manager unless you can benchmark for throughput and then hold teams accountable.

 

The issue is: accountable for what? I say the answer to Highsmith's issue is to get the iteration backlog right with the customer and the project team at the point of release planning. Once planned for best value, then bring on the throughput!

 

 

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Happy holidays to all!

Photo

On the eve of Christmas

Best wishes to all for the holidays!

Photo

Quantum computers in the offing?

... the team has demonstrated that it is possible to take photons from two disparate sources and render these particles partially indistinguishable ... [suggesting] in principle that they can connect various types of hardware devices into a single quantum information network.

This bit of quantum news was recently reported by the National Institute of Standards and Technology (NIST) on their blog. And, actually you could say it's a breakthrough that might lead to quantum computers and a whole new era of amazing computational power.  Who knows where that might lead?

I can't wait to hangup the silicon laptop for a photon computer!

Bookmark this on Delicious

Agile and architecture

If you accept this fact—that the choices you make today will most certainly be wrong in the future—then it relieves you of the burden of trying to future-proof your architectures.

—Richard Monson-Haefel, author of 97 Things Every Software Architect Should Know

It continues to amaze how some agile advocates fail to recognize, and even deny, that when you put together something as simple as two objects, you've created architecture (definition: a description or specification of behavior, appearance, structure, and relationship of and among components).

Thus, when some agilists say they need not concern themselves with architecture, or that it is not all that important, I wonder what planet they are on. Attention: even if it's not written down, or put to powerpoint, a system (two objects, or more) has architecture, and their behavior jointly may well be important and worthy of evaluation.

And yes, I'm aware of this agile principle: "The best architecture, requirements, and designs emerge from self-organizing teams", though I'm not alone saying this principle is decidely limited to the small bore and fraught with scalability issues.

My attention was drawn to a posting by Phillipe Kutchen entitled "Agility and architecture koan" for two reasons:,

1. I did not know what "koan" means; I thought I might find out.
2. He quote a truly mindless statement from a LinkedIn group: “Self-organizing teams can decide everything by themselves. So they don’t need an architect.”

• The former means paradox, or non-sensical statement or question
• The latter is just mindless, but to give the widest possible latitude, perhaps the author was referring to a dedicated position called "architect" and not trying to say that team members should not be architects, or worse: there's no architecture per se.

Anyway, I am in the Kutchen school. In a book I wrote about agile in enterprise projects, and in an article Kutchen wrote for Software (an IEEE publication), Agility and Architecture: Can They Coexist?, we both expound on the obvious: architecture is a matter of context, project context, but all projects and all systems possess architecture, whether you want it or not.

And, of course, even unabashed and credible agilists like Dean Leffingwell, author of numerous well regarded books and articles on software practices in general and agile practices specifically, says that as a project becomes more than the scope of one team working:

For developers, architects, and businesspeople who have experience building large-scale systems and portfolios consisting of systems, products, and services—with the extensibility and scalability a successful solution demands—a solely emergent architecture is counter to our experience. We know that some amount of architectural planning and governance is necessary to reliably produce and maintain such systems. Individual teams, products, and programs may not even have the visibility necessary to see how the larger, enterprise system needs to evolve. It can’t simply emerge. Something has to tie it all together......


Even minor, system-level redesigns can cause substantial rework for large numbers of teams, some of whom would otherwise not have to refactor their module. It is one thing for one team to redesign their code based on lessons they have learned; it’s quite another to require ten teams to do so based on another team’s lessons learned.

And no less an eminence than XP's Kent Beck writes:

Architects on an XP team look for and execute large-scale refactorings [and] write system-level tests that stress the architecture....

While the system is little, the architect makes sure the system has just the right little architecture.

In another space, Computing Now, Maurizio Morisio provides a half-dozen links to reputable thinkers about the role of architecture, architects, and the intersection with agile methods.  Take a few minutes, and read all about it!

Source:
Chapter 20 "Agile Achitecture" from Dean Leffingwell(2010). "Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise",  Addison-Wesley Professional. Kindle Edition

Chapter 10, "The Whole XP Team" from Kent Beck (2004)"Extreme Programming Explained: Embrace Change" Second Edition; Addison-Wesley

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Risk or Opportunity management?

What's going on here?

• Venture capitalists put their money at risk and successfully backed a start-up called Facebook
• Jon Corzine took a risk on European soverign debt and went bankrupt, but John Paulson and George Soros took similar risks during the financial crisis and made billions.
• General Bernard Schriever couldn't risk a failure of the fledgling ICBM program, so he developed the Titan and the Atlas concurrently using different designs
• General Samuel Phillips couldn't risk missing a presidential schedule for the moon landing, so he ordered an unprecedented test program to flight test the Apollo multistage rocket as one stack rather than test each stage independently.

Are these examples of risk management, opportunity management, or some combination? And, by the way, is there a difference, and even so, does it matter?

In other words, is "taking a risk" risk management, or opportunity management?
And, is this posting about counting angels on the head of a pin, or is there a worthy point to be made?

Actually, I say there is, in this respect:

• Taking a risk is usually understood to mean taking advantage of an opportunity, an event out of the ordinary, or an event that is off the strategic path. If it works out, the "risk takers" get rewarded, in some proportion to the risk taken: more risk, more reward. If it doesn't work out, either the risk takers are punished, or at the least not rewarded.

• Managing risk is usually understood to mean preventing an untoward outcome that might derail a course of action or unfavorably impact an outcome.  If it works out, the risk managers are rewarded according to the project success, not according to the impact avoided. In other words, successful failure avoidance is not rewarded directly; reward is only indirectly through whatever incentive was placed on project success.

And, in the project domain, project managers, as a matter of routine, are expected to be successful. Rewards are modest, given the expectations. Stakeholders who "take a risk" and are successful are usually much more handsomely rewarded.  This is not a sour grapes argument, just a discourse about risk and reward vs. opportunity and reward.

Dr Edmund Conrow is an academic, an author, an advisor to defense programs, and a skeptic of opportunity management (at least in the project domain, and domains are important because some concepts don't port well between domains).

But, Conrow provides us with a simple but useful definition of opportunity management: "In simple terms, it's a change in direction of the status quo that will leave us--we believe--in a better place than is currently anticipated". And, he says, to purse an opportunity requires "....allocation or reallocation of resources...".

I agree with Edmund: opportunity is a change in direction; and my corollary is: risk is a threat to not changing direction.

In an article written in 2008 in the DoD publication AT&L for March of that year, entitled "Opportunity Management", Conrow disses the idea that risk and opportunity are more or less opposite sides of the one idea that there are events in the life of a project that will push it off track--risk being a unfavorable outcome, and opportunity being a favorable outcome.

Conrow is not an opportunity denier; far from it. He advocates opportunity management in the sense of a search for alternatives, but not after the baseline is committed. Once committed, the baseline is to be managed to hit its targets until some formal baseline change is initiated and approved.

But, is a planned make/buy decision that is deferred until circumstances are more clear an exercise in opportunity management or risk management?

He sets aside, rightly so in my mind, the idea that project managers deliberately ignore four opportunity possibilities advanced by opportunity advocates, saying most competent managers maintain 360 awareness of these types of opportunities:

1. Opportunity to improve the baseline when there are otherwise no risks
2. Opportunities that are the inverse of a risk to baseline
3. Opportunites that arise from the interactions of risks to the baseline, and
4. "Pure opportunites" unrelated to, or different from, the baseline plan

Bottom line: taking a risk and managing risk are different; they both belong in the project manager's domain. The former is a change management agenda; the latter is a baseline maintenance agenda. There's room for both, as there should be.

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Voice of the customer

General James F Amos, Commandant of the US Marine Corps, has taken on the acquistion bureauracy since assuming command of the Corps.

At issue: favored acquisition programs for modern weaponry for the Marine Corps, and to some extent, a rescue of the Marine's mission, now under fire as an unncecessary second land army.



So, when I see in a recent interview where Amos says that he had appointed himself player-coach (his phrase) on a number of troubled projects, I had to read further.

A couple of his thoughts that caught my eye:

 Math decisions are easier than thoughtful decisions based on strategy and what's best for [the mission]

[To his professional acquisition team]: You're telling me it will take 14 years to get the requirements right, develop this thing [a new amphibious vehicle], source select, test, and then field initial capability? You're crazy!

And of course he's right: if we've waited 14 years for major solutions, like the mine resistant reconnaisance vehile developed for Iraq, we'd be five years yet getting it.

Perhaps General Amos should take a page from USAF General Bernard Schriever, the father of modern program management and system engineering, who, the post war 1950s, pretty much invented how to do military weapons programs (the exception being the WW II program for the 'bomb', a program that Schriever did not participate in). In a recent book, "A Firey Peace in a Cold War: Bernard Schriever and the ultimate Weapon", by Neil Sheehan, General Schriever's acquisition methods are explained in a great tale of the Cold War.

His idea is to put system engineering on the front burner, work quickly with prototypes, develop high risk ideas with multiple concurrent solutions, drive hard for the initial operating capability, and don't let better defeat good. In other words, don't let strategy, or strategic purpose starve innovation. Be prepared to accept opportunity as perhaps a better way.

Perhaps, Schriever was the original agilist!

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Risk management -- what a concept!

While the firm encourages risk-taking ....., it also empowers its risk managers — at other firms considered the back office — to constantly challenge even the most senior leaders to keep them from going over the cliff.


"98 percent of my time thinking about 2 percent probabilities.” That is not something you hear from most .... chief executives

Andrew Ross Sorkin

What a concept: bring risk management out of the back office!

Now, here's the problem with that: Risk management is about avoiding failure; incentives reward creating success. It might look like this is two sides of the coin, but they really aren't. Project managers are told "it's your job" re the latter; sponsors and stakeholders are in the driver's seat for the former.

So, senior management follows the money. No news there.

But of course, we are told: risk and opportunities are both part of risk management. But are they really? RM has its own process; opportunities need not apply. Opportunities are managed either in a portofolio, strategic plan, or in a project's change management process. The overlap with RM is coincidental at best.

So, if there firms that put RM on the front burner, I say: more power to you!

Bookmark this on Delicious

Complexity anyone?

John Biaz, a mathematician rather than a project manager, asks some provocative questions from time to time that are of interest to us. The latest in his post on complexity:

What can you do with just a little information?

• Bill Gates’ first commercial success was an implementation of a useful version of BASIC in about 4000 bytes;

• The complete genetic code of an organism can be as short as a few hundred thousand bytes, and that has to be encoded in a way that doesn’t allow for highly clever compression schemes.

This from Wikipedia:

Recent computer hardware advancements include faster processors, more memory, faster video graphics processors, and hardware 3D acceleration. With many of the past’s challenges removed, the focus .... has moved from squeezing as much out of the computer as possible to making stylish, beautiful, well-designed real time artwork

On the other hand, Baez's friend Bruce Smith produced this video (sans hardware infrastructure) in 4KB (that's a rounding error on a rounding error in most programs today). So, don't say it can't be done; don't accept bloat; be lean!

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Keep calm and carry on

Mike Clayton has a suscint post built around this WW II poster--which, itself, has an interesting history--that summarizes ten ideas for stress management (my editorials added; for Mike's annotation, click on the links):

1. Build in planning time
Of course, if you're not a natural planner, this is toughy, and you may actually be comfortable with the stress of deadlines.

2. Give yourself some contingency
Essentially, #1 operationalized

3. One thing at a time
If you are a natural at multiplexing, go ahead. I, for one, have three books that I am reading in multiplex format

4. A problem shared...
Nothing quite like the sounding board of a creative partner

5. Get up and walk around
What works for me is to change venue. Sometimes I take the laptop to a coffee shop. When working in a corporate setting, sometimes I go to an empty conference room.

6. Tidy up 
Or, don't. It depends on if 'tidy' adds comfort or stress

7. Smart snacking
This one never works for me, so I don't keep any snacks around, except fruit

8. Have a rant...
... but choose your timing carefully
Actually, this one's not for me, either in person or by email (horrors!). Better left unsaid that which you can't afford to live with

9. Stress is a part of success
Yes, it is. Everyone needs stress to function; it's a matter of degree

10. Focus on your achievements
Yes, this is a good one from time to time.

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Think like a beginner

"Think like a beginner!"

That's the big take away from an interview with Salesforce.com CEO Mark Benioff. And, what exactly, does that mean, and what does it mean for project management?

Benioff was pontificating on why some established organizations can't get on the page of destructive innovation, and why they can't seem to get past a one-trick success. His take: they don't think like beginners... they don't think like they did when everything was a blank story board and they had no legacy to preseve and no install base to keep relevant.

Example: According to Benioff, failure to think like a beginner explains, in part, why Microsoft missed the mobile market. According to Benioff, who was a Apple guy when Jobs was there doing the Mac, the genius of Jobs was his ability to constantly think like he was starting over. Thus, Apple came in and destructively innovated the mobile market, unlike MS, in spite of both having a large legacy install base of personal computers and PC applications.

And, this is not first time Apple was willing to throw away the legacy, in spite of customer angst. Apple was the first to throw away the "A" drive at time when people had hundreds, if not thousands of records on 1Mb floppies. Instant obsolescence of the installed base. Apple's reply to customers: "get over it!"

So, what about projects? In most cases the project manager is not the product manager, not even the product owner. (Owner vs manager: I'm making a distinction between an inward looking manager and a outward looking manager, the latter having the larger portfolio (scope)). The project manager pretty much builds what the product owner wants, especially if the agile mindset is followed.  There isn't any doubt that Apple project manager's developed what Jobs wanted.

So, is there a place for the project manager to indulge in "destructive innovation"? Yes and no is the indefinite answer. To restate the obvious: anyone can have a good idea. But of course, not everyone takes--or can take--responsibility for consequences. That's where project management comes in: the PM is accustomed to accountability. If there's a good idea--requiring everyone to think like a beginner--there's no beginning if someone does not step up to the opportunity. Someone has to be the risk manager--and guess what, there's no doubt who that is: PM every time.

Bookmark this on Delicious

December 7, 1941

December 7, 1941: A day that will live in infamy!

To see how this ends, I suggest reading Max Hastings' brilliant history of the Pacific war  for 1944-1945, entitled appropriately, "Retribution"

Bookmark this on Delicious

Kahneman and Tversky

Daniel Kahneman and Amos Tversky have written notable papers about the biases that infect and affect project estimates, the business case, and all communications with executives and stakeholders. These papers are simply nothing other than "must reading" for every project manager.

I've posted about these guys and their ideas before.

Kahneman won the Nobel prize for his contributions, and if Tversky had not died in 1996, four years before the Nobel award, he would have been in Stockholm with his colleague for a joint award.

Now, Kahneman is out with a new book, some 500 pages--perhaps best read (or sampled) on an e-reader--to explain another idea. This idea is about how we think and what drives decision-making. Entitled "Thinking, Fast and Slow ", it posits a System 1 process and a System 2 process. System 1 and 2 are not new inventions by Kahneman, but his tour-de-force through the concepts is a work worth reading.

The idea is simple on the outside: System 1 is nearly unconscious thinking--effectively nearly instant reactive thinking. Everything from survival to instant analysis, like finding an open receiver downfield. System 2 is conscious analysis, slower than System 1, though not necessarily slow. These two ideas inform the title of this tome: Thinking, fast and slow.

Kahnenman writes: "Much of the discussion in this book is about biases of intuition.... my aim ... is to improve the ability to identify and understand errors of judgmenet and choice ....by providing a richer and more precise language to describe them."

And, here's one we can all identify with: "Unfortunately, professionals' intuition does not arise from true experience", indeed, executive "... judgments and decisions are [often] guided by feelings of liking and disliking, with little deliberation or reasoning". For the quantitative manager, decision making driven by such intuitive thinking is the height of frustration!

Summary: it's a tome to be sure, but it's a good read, and worthy of scanning and sampling--highlighting and bookmarking in an e-reader (there are many free ones for laptops and tablets).



Now,

Bookmark this on Delicious

To think first

“It took a year of thinking before we built any prototypes,”

Serge Montambault,

Mechanical engineer with Hydro Québec’s research institute

And, to top it all off, his project to build robots to inspect high power transmission lines is a business success.

It's remarkable what thinking will do. And of course, take note that from thinking, the next step was prototypes, not full scale development.

Remember the spiral method? It's a prototype-first idea from the last century, inspired by Dr. Barry Boehm of then-TRW. His idea: you can't be sure of which direction to step off when faced with technology feasibility issues, so take the time to experiment to find the right direction.

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Why plan

It's agile! Why plan?

Do we really need to answer this?

Yes, we do!

If there are no plans, any outcome is acceptable; if there are no plans, there is nothing to estimate; without estimates, there is no reason to measure.

Without measurements, there will be no benchmarks, no improvement, and no answer to the questions of where are we? and what are we doing?

In fact, without a plan, anywhere and anything will do.

"Project management the agile way: making it work in the enterprise"

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.