The mind is an argument

---

The mind is not a single voice but an argument, a chamber of competing voices, and a [problem] occurs when we listen to the wrong side

Jonah Lehrer

If you don't believe this, read one of these books:  "Against the Gods, the remarkable story of risk", "How we decide", or "The irrational economist, making decisions in a dangerous world".

Or, you could take a hard look at the papers of Daniel Kahneman and Amos Tversky. 

---

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

It's agile! Why plan? Why schedule? Why estimate?

---

Remember the Trinity of Estimation? Why plan, why schedule? Indeed, the question might even be: Why estimate? It’s all going to change anyway.

The answer -- as we discussed a couple of weeks ago -- is quite clear:

If there are no plans, any outcome is acceptable; if there are no plans, there is nothing to estimate; without estimates, there is no reason to measure. Without  measurements,  there  will  be  no  benchmarks,  no improvement, and no answer to the questions of where are we? And, oh by the way, what are we doing?

The Estimation Trinity feeds forward into Agile Principle 5

"Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get
the job done."

Trust them to get the job done. I say, what job is that?

• It is the job described in the business plan, if you have one, but what if you don't?
• It is the job estimated and scheduled? Ooops, no estimates?
• It is the job as interpreted in near real-time by the functional user?
• It is the job that evolves over several iterations and is adapted to the emergent value proposition? And, where is it we are going with that?

Trust them to get the job done. What is the definition of done?

• Is it done when time/money runs out?
• Is it done when the backlog is fully exhausted?
• Or, is it done when the customer says it’s done, or someone else says
• it’s done?

If you are trying to do a project without management, good luck to you.

---

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

Quality drivers -- four big ideas

---

On slideshare, you can check out a paper I wrote on four big ideas that drive quality, particularly in agile methods.  Here are the points, summarized for the blog:

1. The Focus should be on Customers: Perhaps this is an obvious idea that is on everybody's list, but actually it is the Deming v Juran debate.

• Deming was a product guy--make it right, and make it the right way.  
• Juran was a customer guy--make it fit customer need.  

 Of course, there really shouldn't be a debate; Deming and Juran were both right, but in the end, customers, in the broad sense of the word, pay all the bills!  Customers can only be the ultimate focus because without customer buy-in to the quality of the outcomes, all is for naught.
2. Continuous improvement is a project imperative: There can be no substitute for a learning organization, and that includes project, even short ones.  Every team, group, and enterprise should be a unit in transformation, continually improving performance, capability, and capacity. Plan-do-check-act is nearly sixty years old, but actually it's still relevant, especially the check-act thing.  Take a moment to reflect on what you've done or are going--that's check; and then act to apply learning for improvement.

3. Total participation involves everyone: There is a place for the loner, the eccentric, and the individual contributor, but in general, the best outcomes involve the synergy of everyone contributing.  This may be a little harder with virtual settings, but it borrows a page from the wisdom of the crowds as well as recognizing that every individual can make a contribution, so every individual should make a contribution toward improvement.

4. Societal networking is flattening: Social networking may sound like a new idea, but it's been around since the onset of human groups; just the technology has changed.  What is new, or at least revisited, is the way social networking has flattened the hierarchy.  Now, there's no excuse for misunderstanding the spirit and the letter of the customer's needs: just ask!

Wav 4 four big ideas that drive agile quality

View more documents from John Goodpasture.

---

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

Ah, those requirements!

---

We may not know much about the requirements; our backlog may be slight; but we do know this about that:

1st requirements paradox:

• Requirements must be stable for reliable results
• However, the requirements always change

2nd requirements paradox:

• We don't want requirements to change
• However,  because  requirements  change  ....  is  a known risk, we try to provoke requirements change as early as possible

So writes Niels Malotaux in an interesting 16 page paper describing his version of Agile, titled: "Evolutionary Project Management Methods: how to deliver quality on time in software development and system engineering projects".

Here's what Malotaux calls "Magic Words"

'

•   Focus
Developers tend to be easily distracted by many im-
portant or interesting things. Some things may even
really  be  important,  however,  not  at  this  moment.

•   Priority
Defining  priorities  and  only  working  on  the  highest
priorities guides us to doing the most important things
first.

•   Synchronise [sic]
Every  project  interfaces  with  the  world  outside  the
project.  Active  synchronisation [sic]  is  needed  to  make
sure that planned dates can be kept.

•   Why
This  word  forces  us  to  define  the  reason  why  we
should do something, allowing us to check whether it
is the right thing to do.

•   Dates are sacred
In most projects, dates are fluid. Sacred dates means
that if you agree on a date, you stick to your word.

•   Done
To make estimation, planning and tracking possible,
we must finish tasks completely. Not 100% finished is
not done. This is to overcome the “If 90% is done we
continue with the other 90%” syndrome.\

•   Bug, debug 
A bug is a small creature, autonomously creeping into
your  product,  causing  trouble,  and  you  cannot  do
anything about it. Wrong. People make mistakes and
thus  cause  defects.  The  words  bug  and  debug  are
dirty words and should be erased from our dictionary.

---

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 book of Teams for Portfolio and PEO

---

I'm willing to bet that every PEO (program executive officer) in the Pentagon has read General McChrystal's book*, titled "Team of Teams". This book is this year's book on teamwork for the big dogs: PEO's, portfolio managers, and large scale program managers.

Obviously, it's written in a pseudo-military context, covering mostly McChrystal's time in Iraq as the senior special forces commander, but the lessons are easily ported to the civilian domain of large scale projects and business or agency endeavors.

What's in it for program managers and portfolio leaders
The big takeaways are given by the title of the book:

• The payoff and advantages of teams at small scale -- shared commitment, speed, and collaboration to achieve mission and goal -- are obtainable at large scale
• By corollary, reduction-style organization (or "reductionism" in McChrystal's vernacular) -- by which is meant hierarchical work breakdown with parallel breakdown of management tasks -- is too slow and too myopic, and too prone to suboptimizing for tactical advantage
• Networks replace hierarchies; senior management and middle management are all nodes on a common network.
• As in all networks, multi-lateralism replaces stove-piped escalation.
• There is network access to decision-making data
• Complexity is a world onto itself; complexity is a lot more than complicated, because complex systems and situations defy exact forecasting and understanding

For McChrystal, and especially in a context of time-sensitive opportunities, the first point (dare I say 'first bullet'?) is the main point: it's really speed of decision-making and deployment, made possible by breadth of collaboration.

You can't get rid of some stovepipes
One thing he says that struck me is that no matter how extensive a network, at some point it comes up against the boundary of another network or a stovepipe which is not transparent. Then what?

His solution is to send someone into the other camp to be a emissary and collaborator. In the world of States, we call these people ambassadors. The concept is applicable to stovepipes and other management challenges.

ToT is not a new idea, but McChrystal's insights are worthy
In all the project management books I've written over the past 15 years, I've extolled the advantages of teams of teams, though my experiences are small set beside McChrystal's. So, in some ways, I'm a very sympathetic reader of what McC has to say:

• ToT is not efficient and not inherently lean. Teams overlap; teams have redundant staff and materials; a lot of the network communication is not useful to many who hear it. Reduction style management is F.W. Taylor's management science: everything lean to the point of no excess cost anywhere. But Taylor was not a team guy! (Attention: agile planners. Agile is not particularly efficient either)
• Reduction style plans are fragile: subject to breakdown in supply and timetables, and require expensive re-work when things go awry (who's not heard: plans are the first casualty of reality?). But.... such plans can be the best way to do something if only all the risk factors would go away.
• Complexity is non-linear and may be all but unbounded: Nobody has ever calculated how many game of chess there are. "By the third move, the number of possibilities has risen to 121 million. Within 20 moves, it is more than likely you are playing a game that has never been played before"
• Big data won't save us: Ooops! did McC not get the memo? Big D is the answer to everything. Well, except for the complexity thing. Just ask the climate people to predict the weather. But, the antidote, by McC's reckoning, is to time-box or pin things to a horizon.  Just handle the data and complexity " ... over a given time frame."
• "Prediction is not the only way to confront threats; developing resilience, learning how to reconfigure to confront the unknown, is a much more effective way to respond to a complex environment."

---

* Written with Tantum Collins, David Silverman, and Chris Fussell,

---

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 scope thing ...

---

Does everybody buy this?

Scope is defined this way:
 • Scope is all the things we must do, all the things we want to do, and all the
things we actually do
 • Backlog is the scope parsed into work units, stories, use cases, tasks, and
the like
 • Architecture is the scope mapped into form and function

I hope you're buying; that's the way I wrote in the 2nd edition of "Project management the agile way"

Of course, "... all the things we must do, all the things we want to do, and all the
things we actually do" probably don't fit in v1.0 ... that's why we have v2.0. That's why we do release planning and that's why we parse the backlog to fit project capability and capacity.

Waxing on: There  are  some  must-do's  that  influence  scope— must-do's  as  a  matter  of
governance and must-do's as a matter of custom and expectation.

Now, the lecture: Projects must adhere to standards that have become generally accepted practices; processes and protocols must be applied in a manner that is consistent with certifications; and projects must meet the unspoken demands of the market that, over time, have become routinely expected—demands for reliability, availability,  compatibility,  responsiveness,  and  eco-friendliness,  to  name  a few.

Bottom line: Scope is too important to be left to the customer/user. There's a lot stuff to consider for which they don't bring the clues

---

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

Trinity (of estimation)

---

I've often quoted this estimation trinity:

"Estimation,  planning  and  tracking  are  an  inseparable trinity. If you don't do one of them, you don't need the other two."

• If you don't estimate, you cannot plan and there is nothing to track. • If you do not plan, estimation and tracking is useless. • If you do not track, why should you estimate or plan?

Niels Malotaux

Said another way: if you don't care enough to plan your destination, and track your progress getting there, then any road will do, since anywhere will do.

---

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

Von Neumann on precision

---

There's no point in being precise when you don't know what you are talking about

John von Neumann,
Mathematician

---

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

Architecture ... more about this

---

“Architecture is the primary carrier of system qualities such as performance, modifiability, and security, none of which can be achieved without a unifying architectural vision” … SEI

Who can argue with those words?

Among the agile methodologies that emphasize architecture, in contravention of agile principle , which is pretty much nonsense, I like DAD (Disciplined Agile Delivery) which is more or less where Scott Adler's personal journey in agile has led him.

Architecture in DAD pretty much begins with the idea of “enterprise architecture”:
•    Enterprise architecture (EA).  An organization’s enterprise architecture consists of the various structures and processes of an organization, including both technical structures and processes as well as business/domain structures and processes.  There is always an enterprise architecture, even when it isn’t documented.

Even though DAD allows for the EA not to be documented, a role is presumed called the Enterprise Architect who has responsibility for the enterprise architecture in whatever form it takes. Built into DAD is a purposeful collaboration between project architects—which could be a team of architects at both project office and agile teams—and the enterprise architect.

An architect team workflow is envisioned with four major tasks:
1.    Envision initial architecture. The outcome is most often a model of the product or process as it will be integrated into the business. Although there could be iteration of this model, the initial model more or less sets the vision
2.    Collaborate with business stakeholders. This task is an on-going level of effort which has communication at its core
3.    Collaborate with IT stakeholders. Similar to step 3, but targeted more directly at those who have responsibility for the IT infrastructure which will support the product or process over the life cycle.
4.    Evolve architecture assets. These assets could include artifacts architecture models, reference architectures, development guidelines, white papers, and structured analysis.

DAD architecture value-add
Architecture in DAD is perhaps best summarized by the value-add given as these five reasons for why have a planned project effort on architecture:
1.    Common architecture enables agile teams to focus on value creation.
2.    Common technical guidance enables greater consistency.
3.    Agile architectures enable disaggregation
4.    Common infrastructure enables continuous delivery
5.    Enterprise architecture scales agile

Need more on agile architecture? Did I mention my upcoming 2nd edition to "Project Management the Agile way: making it work in the enterprise"?

---

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 a timecard in your future?

---

As a PM in the government, I had a timecard, dutifully punched each week. In the private sector I never had a timecard. How did my boss know what I worked on?

Actually, in the private sector, and somewhat in a military style of leadership, I was given a mission, some resources, and told, in so many words:

Do good; avoid evil

Admittedly, I was a director and then a vice president, so I was expected to find my way without too much input, keeping in mind both customer and business, satisfying the objectives of each along the way.

But now comes along the 24/7 timecard, or so it seems. I wonder what I would have done with this, as related by David Streitfeld in a recent article?

"[Ms X], a Southern California saleswoman for [company Y], .... was required to download an app on her cellphone that tracked her whereabouts 24 hours a day,.... [Ms X] quotes her manager as saying, perhaps jokingly, that he knew how fast she was driving at all times"

 Did I mention Ms X was released [she says] for refusing to have the app on her phone?

And, then, of course, there's the flap over work practices at Amazon. Nothing more to be said about that here.

Is this really the workplace of the future? Streitfeld goes on to quote Andrew McAfee, associate director of the Center for Digital Business at the M.I.T. Sloan School of Management. “There’s a lot of competition, global labor pools of pretty good quality, automation to make you more productive and make your job more 24/7. These are not calming forces.”

Well hello! Not calming forces? I guess not.
Strap in; this may not be a pretty ride from here on out.

---

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