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