Choking innovation?

The premise of agile teams is persistence: work like you train, and train and work together. These practices are the backbone of good benchmarks -- like velocity -- which is the heart of agile planning.

Then, of course, there is the counter argument: such familiarity drains the innovative spirit; there's not enough exposure to new stuff that comes with socialization -- it takes a village, etc.

And, then there's the counter-counter argument: with the right space planning, even persistent teams will wash up against many socialization opportunites from the lunch room to the rest room to the coffee bar (I don't think water coolers are much in evidence anymore, replaced by the K-cup machine)

So, is there a right answer: does persistence choke off innovation, or does the persistent team provide the vehicle to act on an innovative idea and get it into production more likely/more better?

I actually line up with the latter: persistence for quality benchmarking and effective work practices, but open plan work for the "osmosis of communication" as Alistair Cockburn would say.

And, of course, there's the Allen Curve that gives guidance on how "open" such open plan workspace should be. Innovation falls off dramatically (exponentially) with lack of socialization.

Generational differences

---

Yale student Victoria Buhler recently wrote a term paper that was recently  given some public airing. Some of what Ms Buhler wrote -- as described by columnist David Brooks -- is worthy of note by by project managers who have recruited young grads onto project teams, to wit:

• This graduating generation is very conservative in its appetite for change. Broadly speaking, they distrust the link between action and result.
• They require hypotheses to be tested, substantiated, and then results replicated before they commit to any course of action.”
• There is an obsessive focus on individual improvement: “Time not spent investing in yourself carries an opportunity cost, rendering you at a competitive disadvantage as compared to others who maintained the priority of self.”
• They wonder if the mathematization [sic] of .... policy performs a gatekeeper function; only the elite can understand the formulas that govern ......

The first one is project management 101: we are supposed to be experienced and capable of linking actions and results. Shame on us if this is an issue with a new grad on a project team. A good way to start is with an Integrated Master Plan (IMP) --

An event-driven plan that documents the significant accomplishments necessary to complete the work and ties each accomplishment to a key program event

This last one is particularly close to home for me. In the risk management classes I instruct for PMI eSeminarsWorld I ask about qualitative vs quantitative risk mangement and decision-making. I always get a big majority going with the qualitative. Students tell me it's just too hard to get everyone on the same page with numbers -- too much energy goes into defending the metrics and estimates.

Of course, we bring this on ourselves too many times, citing uncalibrated 'facts' that are not facts at all. When push-comes-to-shove, we often really can't defend the numbers.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Loyalty and Trust

---

From time to time, a profound thought strikes here at Musings. Today, it's a question:

Is it necessary for there to be trust in order that there be loyalty?
Can there be loyalty and simultaneously mistrust?

Spoiler alert: there's no right answer. It's a matter of your values and beliefs, for which there is no proof, validation, or algorithm.

So, where did this come from?

1. In my agile classes, we discuss the desirable/essential elements of leadership in the agile environment. The word trust comes up in almost every student reply; I don't recall 'loyalty' ever coming up (though I did search the archives), either as a quality looked for in a leader or expected to be given to a leader
2. I'm reading a new Winston Churchill biography. The biographers -- William Manchester and Paul Reid -- describe Churchill's relationship with Josef Stalin -- from 1942 onward when the USSR allied with the U.S. and Britain in WW II -- as mistrustful but loyal. I was really struck by that assessment.

So, back to the questions posed above; I think this:

•  I can be loyal to an institution (team, project, business unit, agency) without being trustful of its tactical leadership. However, if the mistrusted leadership is then strategic and becomes the strategy of the institution, then you lose me.
• At a personal level, I can't be distrusting and loyal to a person at the same time. At a personal level, trust and loyal have to go together.
• I think, without knowing, that WSC was loyal to the cause represented by the alliance with the USSR without being trusting of its leadership. I get it; it can work.

And, Mike Clayton has an excellent piece on 10 qualities of leadership -- but loyalty (given or expected) is not among them. So, another point of reference for those looking.

(Disclosure: I resigned an executive position in a large company when I could no longer trust a more senior executive and felt I could not be loyal to him, so that experience probably colors my thinking)

And, ONE MORE THING: you don't get the word 'respect' on leadership attribute lists. I wonder if trust-respect and loyalty somehow go together... could you possibly trust someone that you don't respect? Perhaps, one begets the other.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Agile in fragments

---

I've offered my opinion on "agile in the waterfall", but I'd not thought too much about agile in fragments, to wit: no co-location; little client participation; disjointed work; and low priority outcomes.

Sounds like a recipe for project failure for sure

However, along comes leadinganswers (a prominent agilist) with a piece entitled "agile for fragmented part-time teams". I had to read this one!

The main point of the article is that the backlog management ideas in agile can serve many project situations quite well, even those in which the project is part-time people doing "white space" tasks -- tasks of opportunity that fit in where they can.

There's hardly any commitment to schedule but that doesn't mean that there can't be a commitment to quality in whatever is delivered. And, it need not be software... backlogs work on hardware as well.

And, the agile idea that the team has to get together, even if virtually, on some periodic (schedule driven) or event driven occasion to review the bidding, progress, and problems also drives progress, albeit slowly.

There's more in the article, but the point is made: many agile practices can be used to good effect even if not in a contiguous and conventional project scenario.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

The CIA looks at 'big data'

---

Following up on the meme of the day, to wit: 'big data', I came across the GigaOM conference on livestream.com. (free login required) The conference is long over, but they posted videos of all their sessions dedicated to 'big data'.

If you're an old hand at (intelligence) collection, you'll see the differences immediately between the cold war era and today.

However, the main point here is to look at this through the lens of project management, particularly those of us who've done a data sensor/processor, data warehouse, or a large scale ERP. You'll see some of your project technical and functional issues nicely illustrated.

First, the "never throw anything away" data issue -- bigger gets ever bigger:

And this -- Tom Friedman's "The world is flat" platform idea writ large:

And finally about "sensors", this snip -- think of a sensor as anything that can gather business data, business intelligence, or business metrics -- and you'll get a feel for the scope of the idea:

It's a 30min video; if you don't have that much time, the slides are at businessinsider.com:

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Managing for value

---

One of my agile project management students said this:

My company will not allow us to start a job until we budget the revenue and plan for all costs. We are judged by how closely our projects come to the original planned budget.

To which I said this:

Being judged by the budget is being judged by input rather than output. Your sponsor will be disappointed often, even if you don't spend more than planned. Agile shifts the management to the value of the output which is far greater than the value of the input. Afterall, projects are a value multiplier: spend $10 on the project and get $1000 in business return, for example.

This whole idea of projects as a value multiplier -- as evidenced on the balance sheet if nowhere else -- is the theme of my most recent book (available in Kindle, ebook, and, of course, paper)

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Agile and the System Engineer

---

When we're talking about system engineering, we're generally talking about "The big three ideas for System Engineering":

• Requirements
• Architecture
• Validation

There's certainly nothing incompatible with the Agile Principles or the Agile Manifesto among those three.

Let it be said: We're from System Engineering, and we're here to help.....



Really? What can SE do for we agilists?

• Requirements: It's true that SEs are accustomed to structured analysis, decomposition, and lots of 'shalls' and 'wills'. Nonetheless, motivation to do requirements -- to develop not only a narrative from the many disparate statements, but to also fashion an architecture that supports the whole collection of requirements -- fits the agile need nicely.
  
  The big transition for SEs is making the move from a traditional 'shall and will' project to an agile project of conversational style requirements. Now admittedly, some SE can't/won't make the transition, but others will, and their skills are very applicable
  
  SEs are good at elicitation, modeling, risk assessment, and logic... all necessary ingredients when working with use cases and user stories. Hopefully, you're familiar with some of Scott Ambler's stuff on agile modeling, etc... all system engineering, all day.

• Architecture: A close cousin to requirements is architecture -- structure, interfaces, large scale design, and interrelationships. The big deal here is allocating requirements to the major objects, defining the object relationships, and adjudicating conflicts that would compromise coherence, cohesion, redundancy, and diversification.
  
  
• Validation: Validation -- checking things with the customer -- is not that much different, except for timing: more early and more often in agile compared to the traditional. But why SEs in the validation? Mostly, to bring the big picture and largest scale to validate the architecture (lower level validation is largely a team effort with various layers of release tests and integration tests). Such big picture stuff reassures the sponsor, gets marketing fully on board, and if there's to be manufacturing or post release support, then those entities can get on as well.
  
  You've probably seen this V-model if you're a regular reader. It's basically the SEs view of how the project comes down. Validation just completes the loop with the original narrative (shown here as the Concept of Operations)

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting