Scope creep flavors

---

Can there be scope creep in Agile? Doesn't agile define it away in a stroke: "Scope is whatever is prioritized in the backlog that fits within the budget (OPM, other people's money) and the time. The backlog changes all the time, but that's not creep, it's just backlog management."

What I just wrote is a "best value" definition of scope. But, sometimes it doesn't sell.

I credit my agile students with these observations about "creep", to wit:

Project scope creep: it may be well and good that a true pure play on agile has no conception of scope creep, because the backlog is simply rebuilt as a zero-base-backlog (ZBB) after every iteration -- if not after each iteration, then certainly after every release.

Consequently, after every release, you should be able to stop and be satisfied you've delivered the best possible stack of high value objects. Amen!

Resource scope creep
On the other hand, if you can't get commitment for dedicated teams because the resources are needed elsewhere, then you are saddled with the overhead and inefficiency of rolling out and rolling in resources. This is resource scope creep -- spending more on resources' training, recruiting, and assimilation than the budget allows.

Clearly, this is a different flavor than project scope creep.

And, it's been around since forever!
Who's not heard of "resource plug-and-play"? The plug-and-play process: just define a role, line up the role with appropriate resumes, pick one, plug him/her in, and you're off to the races!

• For more on plug-and-play, see the work of F.W. Taylor and "management science" wikipedia.org/wiki/F._W._Taylor

Agile to the rescue!
The fix is in: a pure play in agile means having fully dedicated teams that use the inevitable white space in the team schedule to improve the product -- more testing, more refined refactoring, working completely through the technical debt -- but not to get off the team and go elsewhere, only to return later.

Ooops!
The idea of giving up on matrix and other plug-'n-play resource schemes is pretty much opposed by managers not willing to give real agile a try.

Shifting from input to output
Again, it's an input/output focus tension... managing the white space by moving resources around is an input focus; leaving resources in place to use the white space for quality is an output focus.

Traditional schemes often put resource managers in charge of finding resources for the project manager. Obviously, those resource guys are going to focus on getting their job done according to their metrics. Agile schemes are a bit different: once the resource manager has given up the resource to an agile team, it's the team leader who's responsible for getting good productivity and managing the white space on behalf of a best-value product

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Who knew? Estimates are not free!

---

The title of this blog says it all: Who knew? Estimates are not free!

In a recent email blast from Mike Cohn, who -- by the way, wrote the book: "Agile Estimating and Planning" -- we learn this wisdom -- hopefully, not hearing it for the first time:

I have no problem with a boss who asks a team to provide an estimate for how long a huge set of product backlog items will take to deliver.

There could be hundreds of items – perhaps even thousands, and I have no issue with the boss asking for an estimate.

I will be happy to provide a boss with that information.

So long as the boss understands that information has a cost.

And, so there you have it: No free lunch!
And, hear this: real agilists do estimates! (Mike is as real as they come)

From whence they come
Estimates are not something one has on the tip of their tongue, like that oft-practiced elevator speech about the benefit of this project.

No, common sense -- which we all have some measure of -- tells us good estimates take a bit of time, and that time should be set aside in the project schedule and budget. And estimating, and its close cousin forecasting -- which some define as assembling and integrating estimates -- should not be expected to be "other duties as assigned", only to be handled in the "white space" of the project day.

Nope, estimating and forecasting are legitimate tasks, and there's none better to do them than some of the project's finest -- our corps of SMEs.

And more
And, as if all this is not enough to spin heads, real agilists also use Monte Carlo simulation to develop and validate estimates!

Gasp! Statistics and agile... can this be real?

But yes, it's real! Tony Magennis tells us so in his small book: "Forecasting and Simulating Development Projects" (in spite of the fact he tries to get your attention with #NoEstimates Forecasting)

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

And then there were systems

---

I was reading Matthew Squair's course materials on System Safety Fundamentals when I came across this slide:

"Life was simple before World War II. After that, we had systems."
Rear Admiral Grace Hopper (USN)

Ya gotta smile at that witicism!

The Admiral Dr,of course, is best known for inventing the system "bug" when she literally found a dead bug in in an inoperative computer system. She retired from the Navy at age 79 in 1986 after serving about 50 years.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Getting to 100,000

---

Hey! If you've been reading my "stuff", then thanks!

And, of course, this blog passed 100,000 page views some time ago, so I appreciate all the readership, to be sure.

Oh, did I mention: Read my books!

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

The up's and down's of risk

---

Here's my observation:

Any large bureaucracy with the inevitable personal and public politics, territorial protections, and constant tussles for dominance will have risk attitudes that tend to run vertically, not necessarily shared, consistent, or coherent laterally by process.

So, as a transaction progresses laterally through an organization, it will be buffeted or influenced by different risk attitudes as it crosses vertical boundaries in the process flow.

And, of course, as the apparent risk changes -- I say 'apparent risk', but I'm really referring to the transaction's utility -- then the SWOT of the transaction changes complexion.

In other words, what may be of great utility to me won't necessarily be of great utility to you -- so I'll support the transaction -- it's an opportunity -- but you may not -- it's a risk -- and so it gets stuck in the process unless "the big guy/gal" kicks it loose.

Counter measures
The way to keep things moving is by finding and then supporting an interest that favors the nemesis but yet is tolerable to you. After all, transactions don't have friends, they just have interests. If it favors me, I'll help push on that rock.

Sometimes, as anyone who has found this magic knows, an interest needs to be created where it does not naturally occur.

Who has not seen a totally irrelevant idea/need/favor attached to something to create the necessary grease to move things along? So long as there is legitimacy, transparency, and lack of personal corruption, so be it.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

The leverage of small teams

---

Author Norman Maclean challenges his readers to address: "What the structure of a small outfit should be when its business is to meet sudden danger and prevent disaster".

With the current flattening of organizations, the day-to-day emphasis on team work in small work units, and the demonstrated potential that a small group can make a decision wielding enormous business leverage (how big was the team that decided to attack the World Trade Center in 2001?), Maclean's challenge is particularly timely.

In thinking about how to answer, you might consider:

• Team structure (and protocols)
• Various models of behavior (tolerance or not for chaos and change, etc)
• Structured frameworks for change process, etc
• Empowerment of improvisation (Mann-gulch),
• Virtual small team loose coupling to collective culture (the work of Geert Hofstede on culture), and
• Norms of respect (talk truth to power, etc)

Sudden danger certainly brings trust into the frame: would you trust a stranger to get you out of trouble? Perhaps, if there's no one else around, but your instincts are certainly going to be to turn to someone you can trust. And, trust and safety are certainly constituents of successful teams. My experience: trust doesn't scale too far, so the smaller the better as regards a close knit.

Preventing disaster sounds like there could be advance planning and premeditation to put the right protocols in place -- fire, flood, nuclear breakdown, etc. But also practicing the escape mechanism -- some may be on-the-shelf and largely untested -- do they actually work as intended?

The Gulf oil spill of a few years ago comes to mind. Sometimes, the small team on duty in the middle of the night is all there is between disaster and just another day at the office.

And, how does a structured framework for decision making process and decision fulfillment really work when stressed to the limit? My experience is that they are often tossed overboard pretty rapidly to be replaced by some process that is stress resilient.

Indeed, I often asked: why don't we use the latter routinely? Why is it the extreme solution instead of the usual solution? Answers: too expensive for long term sustainability and lack of scalability. "It" works on a small scale among a trusted and dedicated group, but not likely as the team grows into a "group".

Improvisation saved a few in the Mann-Gulch fire disaster, and many such disasters since. For a good reading on this one, go the link in the first sentence of this posting.

Intellectually, we probably all know that culture either encourages or impedes quick reaction responses to extreme situations, including the cultural acceptance of talking truth to power (and, by the way, the power respecting the message and the messenger).

But, its hard to push culture through an Internet cable. So, sometimes a small team is more like a small group and does not really have the advantages of a close knit team. For example, the norms of small close knit teams are almost always sufficiently informal that the message is aired and the substance often gets heard.

So, one summary observation: as you empower small teams you are empowering leverage: the ability to have large influence with modest effort... Can you handle it?

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Is "pi" infinite?

---

If you're a numbers person looking for a 4 minute break with some humor attached, you'll love this rant about "pi", that number that describes the ratio of circumference to diameter of circle.

And, if you not a numbers person, you'll still be entertained with this very clever explanation of where "pi" fits in the numbers scheme.

In any event, it's very entertaining and a neat way to spend 4:19min.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Microknowledge vs Micromanage

---

Robert Gates, former U.S. Defense Secretary, recently wrote in his memoirs that a strong and effective leader in a big and complex organization needs to put the time and energy into acquiring "microknowledge" but refrain from "micromanagement.

An interesting thought, to be sure. Let the emphasis lie on "... put in the time and energy... " This stuff is not free. Didn't Gladwell say: 10,000 hours to be an expert? Well, microknowledge is not 10,000 hours worth; indeed: most Defense secretaries don't even serve 10,000 hours.

On the other hand: "Microknowledge"? What's that?

• Think of it as the knowledge you would need if you were to micromanage -- thus, it's the knowledge you use to assert leverage, influence, and legitimacy over those you do lead.

In other words, you need to understand the traffic while you resist the impulse to direct the traffic -- others can do that for you. (Think of the scene from the movie "Patton" when the General himself is standing in an intersection of tangled tank traffic directing their movements... you probably don't want to do that, even though with microknowledge you might be successful)

• And, it's the knowledge you use to make decisions about delegation (this individual can likely to "this" but would not be good at "that"...) and assess performance.

But, of course, there's a dark side: microknowledge also what feeds the old saw: "he knows enough to be dangerous, but not enough to be effective" If this said about you, then you've crossed the line from legitimacy and leverage to nuisance and nemesis... Back off!

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Swimming with Agile and the WBS

---

WBS? Agile? Swim lane?
Do all these belong in the same paragraph?

The WBS can still have a valuable place in the agile project, but at a higher level -- less detail -- and certainly ties product development to other swim lanes or work streams in the project, and certainly the WBS applies to other than development that is going along with agile.

Some caution: "swim lane" and "work stream" have the image of relatively few points of contact and interface -- at the beginning, at the end. In an agile project, there are many scheduled points of contact with these other streaming activities, not least at every release review.

Ooops! You don't know what a swim lane is? We read at Modern Analyst.com that a swim lane is a process diagram with this feature:

... swim lanes communicate additional information about who performs the activity or when it takes place. [Consequently] it’s typically a preferred best practice to include them.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Decline -- Maturity -- Growth

---

A few thoughts about decline, maturity, and growth insofar as they affect the choice of projects, given scarcity (and there's always scarcity):

• The real test between maturity and decline is whether or not there is new investment going into the business.
  
  In the decline stage, the emphasis is on cost control, efficiency, and getting the most out of existing product with existing customers; there's little or no investment beyond required maintenance. Over time, product will obsolesce and customers will move on.
•  
• If there's investment going into finding new customers with existing product, that's probably a mature organization surviving.
• Working back to compare maturity with growth, the difference here is that with growth investment is going into both customers and product, keeping both fresh and competitive.
•  
• Also bear this in mind: These ideas are not limited to private sector businesses; government agencies and NGO's have all these same attributes.

And, here's a challenge question:
When is an expenditure a cost and when is it an investment? Sponsor attitudes are usually quite different depending on the view point.

My answer: It's an investment when it goes toward making the future different from the present. That is: it's aimed at strategic differentiation -- to wit: start-up and growth. Else, it's a cost required to keep things moving along as in the present for maturity and decline.

People, too
And, you can extend the argument to people: the CFO carries people on the liability side of the balance sheet -- creditors (they provide time and talent) to whom we owe benefits, salary, etc. in return.

But, what if you're out to hire the one best person to do a task and make a strategic difference toward growth? Investment (asset) or cost (liability).  If an investment, hopefully you've got their scorecard set up to reflect the ROI demand.

  

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Risk or opportunity?

---

Here's a challenge question I often put to my risk students:

If you are challenged by your sponsor (or circumstances) to take a risk on a new and unproven technology, process, or supplier/partner for your project, what is your likely attitude
1. Would you be more likely to put it on the risk register to be managed, or
2. To evaluate it as an opportunity to be exploited, shared, accepted, or enhanced?

I make the point: There's no school answer; there's no "right" answer.

A student replied:

• 1) Depends on the inherent risk culture of the company. Is it risk adverse or not? Risk adverse companies I notice tend to more setup up project KPIs whereby it's in the PM's benefit to keep a tight rein on any possible new circumstances and almost treat any deviation as a negative one that must be controlled immediately.
• 2) Support from your project sponsor and overall stakeholders. This probably fits into point 1 above, however is your sponsor okay with the project possibly running over budget /schedule to see the introduction of the new concept or okay for the project to be possibly re-baselined? Do your stakeholders see this as a positive introduction, negative introduction or just plain neutral to the whole thing
• 3) Depends on when the introduction of the circumstance occurs. If the new technology, process... is introduced in the early stage of the project (e.g. project initiation or even planning) I would see it more as an opportunity to be exploited. Otherwise, treat it as a risk and apply it to the risk register.
• 
  

To which I replied:
The theme of reward/punishment or risk/payoff that runs through your comments is at the heart of the discussion question.

Your observation seems to be: That PMs are often -- too often perhaps -- scored/rated/rewarded on fidelity to the "input" side of projects. That is, they are scored/rated/rewarded on the volume of resources consumed/invested -- cost, schedule, plant/equipment, hours.

I agree (with the student); this is the way many scorecards are set up and the way many comp plans are drawn. That's too bad. The true value of the project is on the "output" side: Deliverables useful to the business for which the project investment "was worth it". 
 
Thus sponsor attitude is a key factor, as you (the student) note. But is your specific sponsor an investor or a resource manager?

The former takes risks; the latter is averse. The former is more output focused -- results with value; the latter is all about delivering according to the plan -- the plan uber alles.  If an investor, hopefully they are endowed with judgment and wisdom is required on the part of the investor, thus to not preside over the rags--riches-- rags cycle of bust-boom-bust. 

Understanding which risk culture you are a part of is key to your (the student) personal success, though the rogue -- if successful -- is often celebrated for both bravery and foresight... if you have the stomach for it.
 


  

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Two cultures by C.P. Snow

---

I've just finished reading "Two Cultures" by C.P. Snow which is a posit and explanation of his observations about science and engineering on the one hand, and the humanities, art, and literature on the other. To wit: two cultures

Written during the early years of the space race in 1959, Snow observes that the arts and humanities people seem oblivious, ignorant, and befuddled of and by technology. They hardly know it exists, and what they do know is only functional.

The impact of education methodology and objective
In part he attributes this state of affairs to the strategies and goals of education from highschool through the university. In Snow's home country in England -- describing 1959 -- social class informs an educational class and approach. Proper gentlemen simply don't study science and engineering.

He contrasts England's structured (class driven) approach with the looser approach in the U.S. with it's emphasis on critical thinking education, and the emphasis on factual recitation in the Soviet Union (China was not on the chart in 1959)

Even though Snow's writing is four decades in the rear view mirror, it nonetheless has relevance today. One is led to think of Microsoft vs Apple when he speaks of engineering vs art, but Snow is really thinking on a larger canvass.

And, he observes that science and engineering are likewise bifurcated with the pure science scientist unable to understand or communicate with engineers, though less so the other way around.

Project and business impacts
I've got some personal experience with this phenomenon, having worked for an engineering company that prided itself on its ability to develop and manufacture. We all but didn't hire anyone for an engineering job jar but a college educated engineer.

And, we were always befuddled by our inability to win jobs when broad canvas "critical thinking" was what the customer wanted. I always felt it was because we were too stove-piped on engineering... we were in our culture, and any other was pretty foreign.

Now by coincidence comes an essay on exactly that point about having embraced a cross culture environment, only with a different outcome. We learn that Intel, that chip engineering company with exquisite design and development talent, hired an anthropologist to lead their strategic innovation as Director of User Experience; and other social science folks to look at other product trends, utility, and impact.

In fact, the department is over 100 people, mostly doing this:

[as] a skunk works of some 100 social scientists and designers who travel the globe, observing how people use technology in their homes and in public. The team’s findings help inform the company’s product development process, and are also often shared with the laptop makers, automakers and other companies that embed Intel processors in their goods.

OMG! An anthropologist? You can't do that! And, this particular scientist is off the page on other factors common to engineers, like having quite liberal politics. 

Talk about two cultures and the way to bridge them!

 

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog