Sunday, May 22, 2016

The value of an idea


"Managing project value" has been a theme I've written a lot about -- I've even written a whole book about it (Did you notice the book cover below?)

So, I was fascinated with a series on the Kahn Academy about the value of a start-up. Admittedly, venture start-up is a little off the bore-sight of a project, but not that far off. This because a central tool in my thinking is the "project balance sheet" between the business (value, resources, commitment) and the project (deliverables, schedule, resource consumption).

The main tool in the business value presentation by Sal Kahn is the business balance sheet, beginning with the value of an idea, and the value of critical or unique skills.  These assets are balanced by a valuation, first just a division of made-up equity, but later by a division of real money.

Somewhat like agile ideas, and other incremental methodologies, Kahn up-values the idea each time there is something concrete to show that is progress toward making the idea a business reality. Ultimately the market makes the valuation, but in getting there it's much like the accumulating value earned along the way by more and more deliverables.

Give the series a look and listen; there's much to be learned.



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Tuesday, May 17, 2016

SCRUM is about people


Looking to hone your people skills and tie into SCRUM?

Here's a seminar -- free even you are not a member -- that is more or less on the theme: "SCRUM is about people".

http://membership.scrumalliance.org/page/Scrummasterwebinar/ScrumMaster-or-Armchair-Psychologist.htm




Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Saturday, May 14, 2016

Truth and myth


Glen Alleman recently quoted Kennedy:
For the great enemy of truth is very often not the lie ― deliberate, contrived, and dishonest ― but the myth ― persistent, persuasive, and unrealistic. Too often we hold fast to the clich├ęs of our forebears. We subject all facts to a prefabricated set of interpretations. We enjoy the comfort of opinion without the discomfort of thought. ― John F. Kennedy

And so we have lots of myths in our industry:
  • Projects don't fail using Agile methods -- actually, some do
  • Earned value projects have better success rates -- probably not. EV is not the problem, nor likely the solution
  • Smartphones with encryption can't be opened -- well, that one got shot down
  • No encrypted file is safe -- actually, some are, though somewhere there is a "plaintext" file


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Wednesday, May 11, 2016

Technical debt -- A definition?


Technical debt: we've all written about it; I've described in my book, Project Management the Agile Way (see below), but I guess the industry has never settled on a formal definition.

I've always thought of it as a "punch list" that is a "debt" that must be retired in the future .... stuff that needs to get DONE or fixed so that we can say to the sponsor: hey, it's DONE and the QUALITY is built in.

I saw this definition recently. Frankly, it's a little too formal and I think it actually misses the point that debt may be as simple as a low level test not completed; a color not made right; a functionality with a bug that occurs very infrequently, etc.  Nonetheless, here it is for your consideration

In software-intensive systems, technical debt consists of design or implementation constructs that are expedient in the short term, but set up a technical context that can make a future change more costly or impossible. Technical debt is a contingent liability whose impact is limited to internal system qualities, primarily maintainability and evolvability [SIC].

If you click back to the original source, you pick up on this explanation which adds a bit of color commentary, to wit:

This metaphor is in essence an effective way of communicating design trade-offs and using software quality and business context data in a timely way to course correct.

While other software engineering disciplines such as software sustainability, maintenance and evolution, refactoring, software quality, and empirical software engineering have produced results relevant to managing technical debt, none of them alone suffice to model, manage, and communicate the different facets of the design trade-off problem at hand.

Of course, I take a bit of issue with the last phrase "design trade-off problem at hand": technical debt is not exclusively -- or even -- about design trades per se; as before: it could be as simple as a low level test not completed. One wonders if the guys who wrote this stuff have actually ever done it.


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Sunday, May 8, 2016

Engineering brillance, but not a visionary


Here's a good TED talk as an interview with Linus Torvalds, the geek of geeks, and inventor of LINUX and Git

Linus Torvalds transformed technology twice — first with the Linux kernel, which helps power the Internet, and again with Git, the source code management system used by developers worldwide.  "I am not a visionary, I'm an engineer," Torvalds says. "I'm perfectly happy with all the people who are walking around and just staring at the clouds ... but I'm looking at the ground, and I want to fix the pothole that's right in front of me before I fall in."



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Thursday, May 5, 2016

Sprint plan: common sense goes here


Now, let's here it for common sense! More and more I see this asset creeping into the advice we get about Agile, and even more so about how to handle the various things that show up in a sprint.

The latest: trying to "freeze" hard the sprint backlog may be impractical. It may be more slushy than a hard freeze. [Didn't we all know that all along?]

In an email blast of a blog posting, guru Mike Cohn tells us that sprint teams may be exposed to changes during a sprint. He calls them "interruptions", and so that is probably a better term, since all interruptions are not changes in scope, but they may bring about changes in the plan to apply resources to the sprint backlog.

However you look at it, Cohn uses this image to explain that "stuff happens":
Of course, every author who writes about Agile, including myself in both editions of my book (see below), writes about the need for white space, unallocated or unplanned time, or buffer periods, to include whole sprints as buffers (zero-scope sprints)

My own experience was with the Air Force on a back office project with a joint staff: On certain days, the military staff members would be on the parade ground or off on some exercise rather than being in the project space adhering to the schedule. Some planning for "corporate overhead" required, to be sure.

But, beyond the overhead, still it is that "change happens" and is brought to you by none other than your product owner or product manager. Though these folks are chartered to maintain discipline re scope changes, sometimes the change invades what is otherwise "iceland" (small i) ... the land of frozen sprint backlog. 


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Monday, May 2, 2016

Fault and Root Cause Analysis


FARCA -- Fault and Root Cause Analysis -- is what you do when you've got observations and symptoms of outcomes, but no real supporting explanation of the underlying causes and failure modes.

Every PMO admonishes: Don't act on symptoms! Get to the 'facts'. Find out what's causing this

And thus: deductive analysis*. When you've got the answer; now you must discover the question.

Naturally, there is the "five why's" analysis to kick it off: ask why five times in a indentured set of questions. You may indeed get to the root cause.

But, if you really need to do analysis, then here's a methodology training aide in just 71 pages!


*[Of course, there's the corollary, Inductive analysis: You got the question -- what happens if ... -- but you don't have the answer. See: "For want of a nail ..." ]


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog