Sunday, August 30, 2015

Dead horses in the PMO



The code of tribal wisdom says that when you discover you are riding a dead horse, the best strategy is to dismount. In the [project office], we often try other strategies with dead horses, including the following:
  • Buying a stronger whip;
  • Changing riders;
  • Saying things like ‘this is the way we’ve always ridden the horse;
  • Appointing a committee to study the horse;
  • Arranging a visit to other [PMOs] to see how they ride dead horses;
  • Increasing the standards to ride dead horses;
  • Declaring the horse is better, faster, cheaper dead; and finally 
  • Harnessing the dead horses together for increased speed 
Thomas Penfield Jackson

I was recently shown this by Alex Walton, principal at 3PMLLC.com, a statement by U.S. District Court judge Jackson, while managing the Microsoft case in 1999. I've edited it with [ ] to apply it to project management.

I'm not sure that Jackson was a happy camper when he said this; a good deal of his ruling in the Microsoft case was reversed on appeal.


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, August 27, 2015

Did you remember FDD?


Stuck on stories? (As a user, I want to .... etc ). Maybe you're stuck on who the user is, especially if it's a system actor.

How about features? They're not stories in the SCRUM story sense, but useful nonetheless. How about FDD as a feature driven methodology? Mike Cohn at mountaingoat software has some similar thoughts about FDD.

Recall the feature syntax:
  • Action ... do onto an Object
  • Object .... which by the Action, returns a Result
  • Result ... you did something to an object and this is what you have as a memorial
Oops! This is all strange stuff? Read my whitepaper on slideshare.net.

The one thing I've always liked about FDD is its emphasis on a domain model, which for all practical purposes is architecture. This is step one of the FDD process:
  • Do the model -- what objects, what actions, what results?
  • Build a features list (did someone say backlog?)
  • Plan the release (but not by time boxes; there are no time boxes, so more conventional planning is required)
  • Design by feature
  • Develop by feature, where develop includes all the testing steps
Unlike some other Agile methods, FDD practices are built around feature teams that are charged with delivering certain backlog (features: action, object, result). And the teams work to more conventional schedules (no time boxes) but still deliver stuff early and frequently, just like other Agile practices.



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, August 24, 2015

The nature of risk -- a white paper


I guess this is Matthew Squair week here at Musings

Check out this very lucid white paper on the nature of risk. You'll like 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

Friday, August 21, 2015

Agile -- shocking revelation!


It shocks, shocks! the sensitivities to read something like this from "leadinganswers", a blog for the thinking agilest. First, the set-up [with my edits in braces]:
"Lots of this agile stuff is hypocritical, it preaches evolution and change, [and] ... Agile methods are supposed to facilitate innovation through iterative development followed by inspection and adaption. They [presumably agile teams] practice the scientific method of measurement and feedback on products and team work; so why are the agile practices themselves magically exempt from this precious evolution?

I believe there are two main reasons; first off, it is to protect inexperienced agile practitioners from themselves. ...."

[Now comes the shocking news!]
The other reason is a little more sinister. Most of the creators, proponents and promotors [SIC] of agile methods have interests in keeping the methods pure vanilla. This is so they can create training courses, certifications and web sites for them. While scrum, as one example, has its specialized ceremony names and products you can neatly market services for it. If you allow or encourage people to change it then the result is not so proprietary and more difficult to defend, promote and assert ownership over. 


Hello! Trying to exploit a somewhat proprietary methodology for the money ... simply beyond the pale!

But, then we get this news, later in the same posting:
First off, in the spirit of full disclosure, I should explain that I was involved with the creation of the agile method DSDM and have worked with agile groups like the Agile Alliance (I was a board member for a couple of years) and helped create several agile certifications (iCAgile, DSDM Leadership, PMI-ACP).

So, I am not immune from the pulls of standardization, but hopefully that adds some credibility to my encouragement to rise up and evolve your methods. The biggest threat to agile I see is not dilution and confusion, it is obsolescence and abandonment because they are not keeping up with new demand of collaborative teams.
Our lecturer goes on: "Agile teams often talk about “Shu, Ha, Ri” progression that describes a three-step process of increasing mastery that progresses as follows:
1.         Shu: Obeying the rules (shu means to keep, protect, or maintain)
2.         Ha: Consciously moving away from the rules (ha means to detach or break free)
3.         Ri: Unconsciously finding an individual path (ri means to go beyond or transcend)"

I associate myself with all of these sentiments. I think leadinganswers is spot-on. My book on agile methods, pictured below, and my book on managing project value, also below, are not methodology bigots. I unashamedly borrow the best. And, so it should be. Anybody who can afford two days in a hotel ballroom can buy the credential of "scrum master". Lets not be a slave to the proprietary.


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, August 19, 2015

Risk managers


Matthew Squair tells us this:
Risk managers are the historians of futures that never were
Wish that it were true, but: Not exactly!

"Futures that never were" never were only if the RM was successful at mitigation, or--on some probability--basis the future never got here. Otherwise, our historians are the prognosticators of futures that actually were--they put it on the risk register and it actually happened!




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, August 15, 2015

The White House and Agile Methods


I don't often look to the White House for guidance on project management, and less frequently (never?) for their view of agile methods. Nonetheless, the White House Office of Science and Technology Policy (OSTP) and the Office of Management and Budget (OMB) are on the case.

OMB in particular runs the gov's CIO Council which coordinates government IT throughout the executive departments by means of each department's CIO. OMB also runs the new (as of August, 2014) U.S. Digital Services.

In turn, the Digital Services has published two guidance documents that are targeted at deploying agile methods throughout the government.

The first is the "Digital Playbook" which describes a dozen or so "plays" (somewhat as a sports analogy of plays).  But the interesting one is the "TechFar Handbook" which you can read and download from this github location.

The TechFar Handbook subtitle is: "handbook for procuring digital services using agile methods". It is structured more or less in a Q&A format, divided among sections. It takes off from the authority in FAR 39.103 which is all about modular contracting authority and procedure. It then shows the compatibility between agile and the intent of modular contracting, and it gives hints on how to "stretch"-- within the law -- to be more modular.

Sounds like it is all going in the right direction. Let's all cheer the U.S. Digital Services



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, August 13, 2015

It just takes too long



Robert Gates, the former United States Secretary of Defense, in a September 2008 speech, said: 
Our conventional modernization programs seek a 99% solution in years. Stability and counterinsurgency missions—the wars we are in—require 75% solutions in months. The challenge is whether in our bureaucracy and in our minds these two different paradigms can be made to coexist”.

Since that speech, the Defense acquisition management system has been revised twice. Now, there is official sanction for faster methodologies with lower overhead.

You can read about it here. Pay special attention to the six acquisition models, and particularly Model 3 for incremental capabilities.

Amen!

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