The Regenerate Web

Long ago there was a large program, the Worrld Wide Command Control and Communications Systems, that was supposed to replace the AutoDIN. After many billions of government dollars, there was no Dial Tone. From the after action report the Software Project Managers Network was founded in 1992 by Norm Brown. From that organization came Little Books. One of the book is titled Project Breathalyzer, October 1997. These are the tests to determine of your project can pass the test.

1. A credible activity network supported by a WBS, Control Account, Work Package structure.
2. A credible schedule and budget for all the identified activities?
3. What deliverables you are accountable for.
4. Your top 5 risks.
5. Your cost, schedule, and technical performance margin.
6. The estimated cost for each deliverable.
7. The external dependencies and how they drive your cost, schedule, and technical performance measures and how you are going to manage them.
8. Your staff has sufficient technical expertise to accomplish the planned work.
9. You have adequate staff to maintain your planned schedule, cost, technical performance measures.

We've used these tests in the following way:

1. Have the project staff answer these questions every week.
2. If there are not credible answers, then go get the answers.
3. Once you get the answers, assess how these answers impact the cost, schedule, and performance of your project.

No matter the answers, you need to ask and answer these.

From the Ask Tom mailbag:

Question:
How do you distinguish between Ten years experience and One year experience ten times?

Response:
I love analogies. When we attempt to describe capability, we most often fall into analogies.

• This person has a Post-It Note mentality.
• We need more band-width in this role.
• We have to get more horsepower on this project.

When I press for articulation, most often the explanation is another analogy. But when I look around the room, everyone knows intuitively what is meant by Post-It Notes, band-width and horsepower.

So, what’s the difference between Ten years experience and One year experience ten times?

Elliott Jaques (Requisite Organization) most clearly depicted these different states of thinking and corresponding levels of work –

• Stratum I – Declarative Processing – the ability to focus on single task, direct output, solving problems through trial and error. Logic consists mostly of opinion without evidence to support.
• Stratum II – Cumulative Processing – the ability to piece together separate elements of a problem, pattern detecting, solving problems through past experience, documented in SOPs, best practices.
• Stratum III – Serial Processing – the ability, not only to see patterns, but cause and effect relationships between elements. Problem solving through comparative analysis, root cause analysis. The ability to sequence discrete elements into an efficient system.
• Stratum IV – Parallel Processing – the ability to handle multiple serial processes simultaneously. Not multi-tasking, but seeing the interdependency, contingency and bottlenecks that exist between multiple systems and sub-systems. Problem solving through systems analysis.

So, now you tell me. What’s the difference between Ten years experience and One year experience ten times?

Please join Shane Hastie and me for a webinar about our Geographically Distributed Teams workshop on Feb 15, at noon Eastern.

Want to make your geographically distributed agile projects more effective? Join Johanna Rothman and Shane Hastie for this webinar where they will discuss their workshop, Working Effectively In Geographically Distributed Agile Project Teams. We’ll address a few of the common problems of geographically distributed agile teams, and then open it up for your questions.

Even if you can’t make the webinar, please sign up so I can tell you about the recording.

From the Ask Tom mailbag:

Question:
As I look at Elliott Jaques model organization, I notice that it is a hierarchy. Over the years, I have heard, or been taught, or read articles about how it is important to flatten out the hierarchy, drive decision-making down to the front lines, closer to the customer. It makes sense to me, but Jaques seems to ignore these new flat organizational models.

Response:
Your observations about Elliott Jaques’ high regard for hierarchy is correct. And these new organizational models really aren’t new. The flat organization, for all its well intentioned “new-ness” is the way things were before there was hierarchy.

Most people see organizational layers as reporting relationships. Who reports to whom? Who is a direct report? An indirect report? A dotted line report? This view lends itself to command and control and the push-back is predictable in today’s business environment. The central question is NOT, who reports to who, but which manager can be held accountable for the output of the team member?

Elliott saw things differently. Elliott was a scientist who spent his time observing both functional and dysfunctional organizations. He didn’t make up warm and fuzzy theories, he observed, in a scientific way. He gathered data, documented his findings and arrived at principles he found helpful.

Elliott observed, in functional organizations, that each layer had a Time Span orientation distinct from the next and that, if you drew a picture of those layers, from the longest Time Span goals at the top to the shortest Time Span goals at the bottom, you ended up with a picture of hierarchy. If his findings had been a circle, he would have reported it to be a circle, but his findings supported hierarchy.

As he examined each layer, he found that problems were solved differently. And the way problems were solved was directly related to the Time Span of the goals each layer was working on.

The value he found, in this hierarchy, was the capability of each successive layer to assist the next layer down with their problem solving. This capability created a value stream for problem solving and decision making throughout the organization.

Where we get screwed up with all this push-back on hierarchy is that we see hierarchy as a reporting structure. The real power of hierarchy comes from its value stream. Here is the way Elliott saw it:

Every employee is entitled to have a competent manager with the Time Span capability to bring VALUE to their problem solving and their decision making.

I hope that by now you see that you have any number of choices for your lifecycle if you are geographically distributed team and you are transitioning to agile. I do recommend a servant leader agile project manager, for coordination and risk management. With people all over the world, it’s difficult to coordinate the project, which leads to more risk.

Scrum is often not the best approach to geographically distributed agile. That does not mean the distributed team should not go agile. It just means they should not use Scrum. If the distributed team can all travel to one place so they can get trained by the same Scrum trainer together, and if they can take the opportunity to talk together to discuss what they need from the Scrum Master then maybe they can use Scrum, especially if they use their retrospectives well. It’s a lot of responsibility for the team new to agile and new to Scrum. If you’re a team new to agile and new to Scrum, and you try this, do yourself a favor and use a coach.

Electronic tools do not always make seeing and managing the risk easier when you first start–tools can prevent transparency until you understand what you are doing. I like starting with stickies or cards on a wall or board, and as the team members learn how to work, and what they, as a team need, then choosing a tool. I don’t see how to choose a tool before you know what tool you need. One tip: do not allow your management to select a tool for you. You, as a team, can select a tool for yourself. You might start with digital pictures of your task board on a project wiki before you decide which tool to use.

Let me recap:

Agile Lifecycles for Geographically Distributed Teams, Part 1 discussed iterations and silo’d teams.

Agile Lifecycles for Geographically Distributed Teams, Part 2 discussed kanban and silo’d teams.

I got all hot under the collar and discussed Why an Agile Project Manager is Not a Scrum Master.

Agile Lifecycles for Geographically Distributed Teams, Part 3 discussed iterations and kanban and silo’d teams.

You should also read What Lifecycle? Selecting the Right Model for Your Project.

If you have several teams all working towards one business goal, you have a program, and that is a different problem. Look for more blog posts on that, later.

These are precisely the problems no one teaches you in project management certification courses. If you have read Manage It! Your Guide to Modern, Pragmatic Project Management, you know I consider knowledge of different lifecycles necessary for project managers.

Project managers who try to control their teams better have a darn good reason–these people are adults. They manage the rest of their lives. Are you trying to tell me they can’t manage their work? And, these are the problems that can cause geographically distributed projects to fail, splat.

If you want to learn to work more effectively on your geographically distributed team, please join Shane Hastie and me in a workshop April 17-18, 2012. We would love to have you.

I am one of those folks who watch the super bowl for the entertainment, not the football. Not just the ads and half-time show, but also the stories of triumph and beating the odds.

During yesterday's telecast, I was struck by the interview with soon-to-be MVP Eli Manning who said that his coach encouraged players to "do their jobs." The point he was making was that each player had a role and needed to focus on executing his role, not worrying about what others were doing or playing armchair quarterback/running back/tight end/kicker/and so on. Team members need to own their jobs and trust their fellow team members to do the same.

We should do this, too.

I am NOT saying that we should focus only on ourselves, work poorly with others, or adopt a survival of the fittest mentality - me, me, me. I am not suggesting corporate narcissism. Regular readers will know that is not my point here because I would never suggest this.

Here is the point: Think about how much better you and your team could be if everyone focused on his or her job, his or her contributions, his or her role within the team. A great team is made up of strong team members.

What gets in the way?

• Some people find it more interesting to think about what others should be doing differently. This is lazy and weak.
• Some people define success as compared to others. This approach will never serve you well.
• Some people don't hold themselves to a high enough standard.
• Some people are not clear on what their role is or how it they are expected to contribute.
• Some people get so wrapped up in the drama of the team that they lose sight of what the team is responsible for contributing. This issue, BTW, is different from being mission driven. I have worked with several health care clients, for example, where the team felt they were dedicated to saving lives and healing but who were not making the connection between their team dysfunction and their ability to manifest the mission.

I see these issues when working with struggling individuals and teams. I have wanted to hit team members over the head with a metaphorical 2-by-4 and say, "just do your job, don't worry about others."

So much energy gets soaked up by this crud. The opportunity costs are HUGE.

I bet we all could do better if we remind ourselves to just do the the work - our work. To do our thing and support others so they can do their things. To define success while resisting the urge to envy or covet other people's lives or roles.

And as managers, part of "our job" is to institutionalize this way of thinking and doing, like Manning's coach apparently did.

“All men can see the tactics whereby I conquer, but what none can see is the strategy out of which victory is evolved” - Sun Tzu, Chinese Philosopher

I'm starting a new engagement to triage an Army program that has "gone off track," and needs to be put back to GREEN. The kick off of the 10 week effort, before the Government comes in June to surveil the systems, people, and processes designed to keep the program GREEN.

The start of the engagment always starts with a wall of truth that contains the work activities. There is a large wall in the conference room, with butcher paper, swim lanes, and sticky notes. The swim lanes are:

• People - who is doing what, when
• Processes - what is being done, by whom, when
• Tools - how is this done, when

This people, processes, and tools catch phrase is usually just that, a catch phrase. We need to turn this into actionable outcomes.

• People - in the best of worlds, you get to pick the people on the team. Try as hard as you can to do this. If no, have a strict screening process. Hold each person accoutable for their contribution. By tough on those not meeting those commitments. It's NOT about the self actualizaiton of the staff - at least as the first priority. It's about project performance. Self actualization comes for performance. Projects are team sports. Teams as assembled to win.
• Processes - process is king once you have the right people. Following the process is how teams win. The process can be loose or strict. The process can be agile or it can be full DoD 5000.02. The notion that agile is not formal, strict, and structured is of course nonsense. Doing Scrum - right - requires more discipline and rigor than some open ended PMBOK style processes.
• Tools - are nice. Tools remove tedium from the project. But tools only work is you have a process and people who follow the process.

Here, the developers were in Cambridge, MA, the product owners were in San Francisco, the testers were in Bangalore, and the project manager was always flying somewhere, because the project manager was shared among several projects. The developers knew about timeboxed iterations, so they used timeboxes. Senior management had made the decision to fire all the local testers and buy cheaper tester time over the developers’ objections and move the testing to Bangalore. The Indian testers were very smart, and unfamiliar with the product, so the developers suggested the testers test feature by feature inside the iteration.

The project manager suggested they use cumulative flow diagrams and cycle time measurements to make sure the developers were not developing “too fast” for the testers. The developers, still smarting over the loss of “their testers” were at first, peeved about this. They then realized the truth of this statement, and developed this kanban board.

You can see in this board, that four items are waiting to go into system test. Uh oh. The developers are out-producing what the testers can take. This is precisely what a kanban board can show you.

The testers aren’t stupid or slow. They are new. They cannot keep up with the developers. It’s a fact of life, not a mystery of life. The developers have to act in some way to help the testers or the entire project will fail. The reason they are working in timeboxes as well as using kanban is that they have several contractual deliverables, that management, bless their tiny little hearts, committed to. The timebox allows the team or the product owners to meet with their customers and show them their progress. (They were deciding who would meet when I last worked with the team.) The kanban board help make the progress even more transparent.

Iteration planning: The product owner and the project manager jointly work on the agile feature roadmap, and the product owner owns the roadmap responsibility for it. The product owner owns and generates the backlog. The product owner and the agile project manager present a strawman iteration backlog to the team at the start of the iteration. They have had difficulty finding iteration planning time that allows everyone to be awake and functioning, bless the senior managers’ little hearts.

Daily commitment: They do a handoff, asking each other what they completed that day and what the impediments are. If you have read Manage It!, you know I modified the three questions to “What did you complete, what are you planning to complete, what is in your way?”

Measurements: cumulative flow, average time to release a feature into the product. They are experimenting with burnup charts and impediment charts. They are still having trouble bringing the testers up to speed fast enough.

Yes, they do retrospectives at the end of each iteration. Yes, the product owners own the backlogs.

I’ll summarize in the final part, the next entry.

(Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.)

“I just can’t seem to get anything done,” lamented Ralph. “It seems that, all day long, people just line up at my door with questions and problems they cannot solve. I spend more time working on their problems than my own problems.”

I asked Ralph how accessible he was. “Oh, I have an open door policy. In fact, I cannot remember the last time I closed my door.”

An open door policy sounds like an admirable leadership trait, when, in practice, it can create unintended results. An open door policy can actually train your team members that you are the fastest way to solve a problem. As the manager, you can become the shortcut that prevents independent research, arriving at new ideas, or formulating original strategy.

On the wall, behind the swivel chair of one of my favorite clients, is posted the following phrase, “What are you going to do about that?”

You see, an open door policy has little to do with the door.

I was talking with a client recently, who was professing his desire for younger candidates.

“Can anyone older than 35 or 40 really know anything?” was his concern.

I sat there, a little nonplussed. “How old do you think I am?” I paused. “No, don’t answer that. Just remember that age is not the issue. You want people who know how to learn and work well with you. You want people who don’t have the same year of experience year after year after year.”

Those of you who have read Age and Agile are Orthogonal know what I think about age and agile. It’s not how old you are. It’s about how well you think. It’s about what you have learned and applied during your career.

In my recent post about Why an Agile Project Manager is Not a Scrum Master, I talked about the ongoing learning I expect a project manager to have. Of course, not all project managers have that. But the project managers who don’t continue to learn have the same year of experiences every year, year after year, do. (The goal of the PMI certification PDUs is that the PMP continue to learn, year after year.)

So, remember, it’s not about how old a candidate is. It’s about how well they they think, and how they have applied what they have learned.

And, you young turk hiring managers: yes, people that old might just know something. And, they might have more maturity than you give them credit for. And, they might not want your job. You can’t tell what a candidate’s value is until you read the resume. So, stop playing age discrimination before the older candidate even gets in the damn door and give them a shot.

Sheesh. Repeat after me. It’s not about how old the candidate is. It’s the value the candidate brings, regardless of the candidate’s age. Young people might not be able to learn anything, either. Sheesh.

Check out this supercharged and amusing talk from Shawn Achor - it is excellent and has the potential to help us all live more fulfilling - and successful - lives. 12 minutes.

A reader asked why the lifecycle in Agile Lifecycles for Geographically Distributed Teams, Part 1 is not Scrum. It’s not Scrum for these reasons:

1. The project manager and product owner start the release planning and ask the team if the release planning is ok. The team does not generate the initial draft of release planning itself. In Scrum, the team is supposed to generate all of the planning itself.
2. The checkin is different from the Scrum standup and the objectives of the checkin are different. I did suggest to the teams that if you want to create a cross-functional team where the functions are separated, if you ask people how they are working together, you might help them work together. Sometimes those questions work, and sometimes they don’t. It depends on the team and whether the people want to work together.

I didn’t mention retrospectives or backlogs in my examples so far, because I took them for granted. Yes, both examples of these teams do perform retrospectives and have product backlogs. They also have agile feature roadmaps, which are on my list to blog about.

The real difference is the difference between a Scrum Master and an Agile Project Manager. A Scrum Master is not a project manager. A scrum master does not manage risk by him or herself. A project manager will take on the risk management responsibility without asking the team.

A Scrum Master has only allegiance to the team. A project manager has responsibility to the team and to the organization. That means that the project manager might feel torn when the organization pressures the project manager to do something stupid. (Although, I just downloaded the Scrum Guide, and the Scrum Master’s responsibilities have grown considerably since I took my CSM with Jeff way back in 2006.)

But agile provides transparency when the organization asks the agile project manager to do something stupid, so it’s easier to retain your integrity as a project manager.

Want to move a feature higher in the backlog? Change the feature roadmap with the product owner and then change the backlog with the product owner. I expect the agile project manager to collaborate on the feature roadmap and the backlog with the product owner.

Want to change the velocity of the team to please some crazed manager? Both the Scrum Master or the agile project manager protects the team in these ways:

• Explain that velocity is not a productivity metric
• Say No and explain why
• Play the Double Your Velocity schedule game
• Or choose some other way to remove this management obstacle.

Agile makes it easy to protect the team. The question is this: does the Scrum Master have other responsibilities in addition to protecting the team or is the Scrum Master full time? An agile project manager tends to be full time on a geographically distributed team. Even on a geographically distributed team, a Scrum Master is not seen as a full time position. Bless their tiny little hearts, managers don’t seem to understand that transitioning to agile, especially for silo’d distributed teams with different cultural norms is non-trivial. They will make room for a project manager, but a Scrum Master? Oh no. Makes me nuts.

Cut corners on quality? I don’t see how. The team doesn’t meet the acceptance criteria on the stories and doesn’t meet their criteria of done for an iteration, and can’t show a demo. How does that serve anyone?

Help a team go faster? This is the one place where a project manager may have an edge over a Scrum Master, and that’s only because of education. An agile project manager is a project manager. That means he or she is actively studying project management, which means he or she is studying lean also, looking into work in progress. (I realize many project managers do not actively study project management.) I have high expectations of an agile project manager, and that is to limit WIP, work in progress, to measure cumulative flow. But, Johanna, that’s a lean project manager. Yes, that’s correct. Why not use all of the tools available to us at all times? This is not to help a team actually go faster, but to provide feedback to the team about their WIP. If everyone takes a story at the start of the iteration and everyone always works on their own story, it’s likely the team is at the slowest possible velocity. It’s worth knowing that, or at least retrospecting about the data. A project manager will gather the data. A Scrum Master, especially one who was not a trained project manager, may not know to gather the data.

I have nothing against Scrum Masters. Some of my good friends are CSTs (Certified Scrum Trainers). However, they are not all project managers, and have not been project managers, and have not studied the field of project management. Some have been. And, the real issue is this: In a two or three day workshop, they cannot convey to a person who may or may not have been a practicing project manager all of their project knowledge.

Organizations do not always pick project managers to be Scrum Masters. And, with good reason. Some project managers are command-and-control project managers. I suspect back in my long-ago past, I was. I gave it up long ago because it didn’t work. Some people never gave up command-and-control project management. Those people are not good project managers for agile projects. They are terrible project managers for geographically distributed projects, where you must work through influence.

You can have self-managing teams that are geographically distributed. You can have self-directed teams that are geographically distributed. But, they don’t start that way. They evolve into self-directed and self-managing teams. They start as management-led teams.

And, especially when they are silo’d teams, they need the coordination of a project manager, someone who will manage the risk between the silos, and someone who has the organizational backing, and yes, someone who has the allegiance to the organization to say, “We need to do this project” to write the project charter.

In a geographically distributed team, the agile project manager writes the project charter either with the team, or as a strawman for the people to edit and approve. Shane and I recommend that the people get together to write it together. We like it if people get together in person. We know how rarely that happens. (Penny wise, pound foolish.) So we teach people how to write a project charter when they are divided in space.

Because until there is a project charter, there is no organizing principle for the silo’d teams. Those developers in France, testers in Belarus, product managers and project manager in San Francisco, they all need something to coalesce around. The charter, which includes the project vision provides that. The iterations provide the project heartbeat.

So, that’s why I don’t think Agile Lifecycles for Geographically Distributed Teams, Part 1 is Scrum. It’s close, but no cigar. I respect Ken and Jeff’s work too much to call it Scrum when it’s not.

Now that I’m mostly recovered from my cold, I can continue the series about lifecycles.

(Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.)

Eminence based medicine — The more senior the colleague, the less importance he or she placed on the need for anything as mundane as evidence. Experience, it seems, is worth any amount of evidence. These colleagues have a touching faith in clinical experience, which has been defined as “making the same mistakes with increasing confidence over an impressive number of years.” The eminent physician's white hair and balding pate are called the “halo” effect. — from "Seven alternatives to evidence based medicine," British Medical Journal, 18 December 1999.

When I hear about new and innovative processes, technologies, or theories of how to cure the world's ills - from energy to new management techniques, I start my quest with the question...

Ya got any evidence your idea actually works in the domain I'm currently working in?

No? Well go get some and come back, I'd love to see it work here. Many times I never hear from them again.

I've used several approaches to collecting and managing ideas over the years. There were URL browsing capture tools that put links into folders. There is of course each browsers ways of saving links. There is MindJet which can do this on your computer and then you can publish the Mind Map to the web. The are several mind mapping tools, The Brain is one that I tried for awhile.

But now I've found what I was looking for, with a few missing features. It's call PeralTree. Not that snappy a title. But it does what I need. Captures web content and arranges it into "trees" that can be navigated with a Flash PlugIn. You can share nodes in the tree with others.

It needs some more work.

• Interface with Outlook for emailing links to locations in the Tree
• A way to cross link, so navigation can move between nodes. That would make it a network navigator

But so far it fits the bill for the perfect idea organizer.

I hope you have a great week. Here is a quick model that I hope helps you shape your week. You choose the path and how many self-imposed barriers you allow to slow you down. Openness - versus defensiveness - enables us to fully trust in ourselves because we take in the world fully and can respond flexibly. When we carry a lot of mental garbage, we rely more on history that might not be relevant for today, inflexible mental models, manic mantras, and motivational posters to guide us. Why do we need to list our values? Answer: Because we are not open enough to fully trust ourselves.

If we're ever going to move away from the anecdotal style books, we're going to need experiments that show the recommended changes actually work. The material to the left, Code of Best Practice: Experimentation is one place to start.

In the beginning of Agile it was all anecdotal. Strong push back came when there were questions about applying those practices outside of personal experience. It is a trait of many disciplines that the early developers have a good idea, but resist attempts to have others assess and verify their ideas. Just try it you'll discover what I discovered. That's good when the project is low risk. But when you're using someone else's money, it's a bit harder to just try it.

Same situation in the business process management domain. Listing all the problems is possibly good, but I doubt many are unfamiliar with all the problems. Listing solutions to those problems in the absence of a domain and a context in that domain, mean the anecdotal information is stuck in the domain and context of the author.

In order to move - credibly move - to another domain, an experiement is needed to show the suggested solution methods will actually work.

This is another aspect of popular books, they are usually missing that experiment in another domain.

Here's my working example

Agile development in the form of Scrum has been around for a long time. It is used in many domains.

There is conjecture that it can be applied to government IT programs. There are conferences about this topic. I've spoken at several and introduced the idea that the Federal Acquisition Regulation (FAR) and the Defense version (DFAR) have much to say about how you manage a program and what methods are used.

The work now is to connect the two ideas - Agile and FAR/DFAR/Earned Value - so both can work in the ways they are supposed to work.

So Back To Business Processes

We've got lots of suggestions on how to un-stick business management. Got any experimental evidence that any of those suggestions actually work? No? Then we're at the same place we were when XP started. You gotta try it before you can say it doesn't work. Not likely when someone else's money is involved.

Yes, you read that right... Value Preposition.

We all know what a value PROPOSITION is... that statement telling everyone WHAT you bring to the table. It's been hammered and expounded and pontificated to death. From organizations to individuals, if you don't know your value proposition by now, you've missed the bus.

But what about your value PREPOSITION? You know what a preposition is... think back to your early grammar classes. Prepositions are those "directional" words: to, from, by, for, with, around, etc.

It's one thing to know WHAT value you bring to the table (i.e., your accomplishments), but do you know HOW that value is being conveyed? Knowing the answer to both is key to branding your accomplishments.

This weekend, I start teaching a new semester AND the first pilot site of my project goes live. For weeks, I've been wrestling with questions about my customers, students, and stakeholders. Am I doing this TO them, FOR them, or WITH them? The answer is all three (depending on what the "this" is).

But it's still an important question to consider. If you do things TO your customers, will they resent it? Everytime Facebook makes a major change, the posts are littered with complaints that they don't care about the users. If you do things FOR your customers, do they perceive it as patriarchal or an entitlement? Or are you accomplishing significant milestones WITH your customers in the spirit of partnership? Another possibility is doing things AROUND or NEARBY people who may not be your customers now, but are watching your current value PREPOSITION to see if they want to do business with you.

Just some thoughts as we collide coast into our weekend.

Power to the Edge: Command and Control in the Information Age, speaks to the integration of traditional management with complex systems in the presence of agility, emergence, and variability of the real world.

This is a book about managing in the defense systems domain and the technology advances that push the decision making processes to the edge of system.

This is about architecture of the system. The human system, the techncial system, the operational system, and the governance system, and the environment in which these systems are embedded.

While the book is focused on military systems, it is applicable to other complex systems. Military systems have many if not most of the attributes of business systems.

They have strategy, emerging requirements, adversaries who want to put you at a disadvantage, limited budgets, limited time to deploy the solution, conflicts internally and externally that conspire to have your efforts fail.

The notion of centralized planning and decentralized execution has merit in modern software development processes and the business they support. Planning is NOT used in the way agile software developers use the word Planning - wrongly BTW. Planning in the defense domain, for defense processes, and the programs that deliver the systems used in those processes means Strategy Making.

All Planning is Strategy Making. So when you here an agilest say Responding the Change Over Following The Plan, they should really be saying following the schedule. The irony of course is even the formal DoD Earned Value Management world, there is a nice little form titled BCR (Budget Change Request) and its used all the time to make changes to the cost and scehdule baseline. Whym beacuse things change. But if we're changing our Strategy all the time, then there's a much bigger problem to solve.

Calculating Outcomes

To follow on a recent theme of what's wrong with populist book? is shown in this example. Integrating Air, Land, and Sea Operations, which speaks to integration of complex systems into a System of Systems that behaves in ways not definable in the beginning. This is done through intelligent agents at the nodes of the network. This is called network centric warfare.

The Integrated Master Plan (IMP) is a Strategy for the successful completion of the Program. Like all strategies, a set of hypothesis are needed to test the strategy. With these hypothesis testing processes, there is no way to known if the strategy - the Plan - will work.

This is a sample of a book where popular ideas are presented and at the same time actionable outcomes are provided.

“But, the resume is their experience,” Alisha complained. “It’s the central document I use, in the course of an interview.”

“The problem is, you look at the resume instead of the role you are trying to fill. You ask questions about the resume, instead of asking questions about the role and the candidate’s experience and capability related to the role,” I responded.

“But the resume is their experience,” Alisha repeated. “It’s the biggest piece of paper in the process.”

“The reason the resume is the biggest piece of paper is because you haven’t documented the Role Description, and you haven’t created a bank of questions off the Role Description. You are not prepared.”

“That’s not true,” Alisha protested. “I have several prepared questions going into the interview.”

“How many is several,” I asked for clarification.

“Well, seven or eight,” she replied.

“What if I told you, that you needed 60-80 prepared questions to feel really prepared?”

When there are statements like this, in the absence of a domain and a context of a domain, it just reinforces why I don't recommend you read any populist books on a topic if you have any skills at all of getting to the first level of actual technical context for that topic.

So let's start here with a survey of the topic from the non-populist point of view - that is actionable. That is from the point of view of people who want to calculate something, make a decision on the outcomes from that analysis.

Nothing wrong what so ever with those populist approaches. But one test that has served me well over the decades is can I calculate something with this person's product (book, paper, or article)?

No? Then I may not be able to calculate something directly from the author's work, but I'd better be able to find out how to do it in an appendix or a reference.

Still a No? Then is there something there that will lead me to the next level of understanding where I can start to see how I can calculate something. Here's the recent example about Moving Beyond Populist Books.

What's this means is that while the populist books may be informative to many - and we need a lot more informed people than we have now - these populist books and materials quickly run out of steam when we want to actually make a decision that involves money, time, resources, risk, commitment of someone else's stuff. In other words we need to know quantitatively and analytically what the probability of success will be if we follow that authors advise.These populist books play a role of starting the conversation, but fail to complete the conversation - in many cases - with actionable outcomes. They point out the problem but not the actions need to create the solution. Knowing the problem is necessary but not sufficient.

I can hear the populist authors squawking now.

What! How dare you critize my popularizaiton of this critically important topic with your lame need to actually apply this idea in a quantifiable manner. 

But their role is to popularize a topic, not necessary do the calculations needed to solve problems with the popularization.

So if you look at the reading list of the paper above, you'll see books, papers, articles that DO provide actionable outcomes. Once you've digested the populist ideas, take a tour of those to see if there is anything there you can put to work on your own complexity management problem.

Don't get me wrong. Populist books are fine. But they are just that populist not the engineering books I need to work the problems in front of me.

For some more background on complex systems in the world I work see:

• NDIA Human Systems
• Verification and Validation in Complex Adaptive Systems
• Cybe Space: The Ultimate Adaptive System and the Operationalizing Agility 
• The Agility Advantage: A Survivall Guide for Complex Enterprises and Endeavors. This eBook will freak out the agilest who don't understand the notion of Command and Control is mission critical paradigms, where agility must operate in the presence of 100% Mission Success.