We don't do manifestos

---

I wrote this a couple of years ago; not much has changed:

You gotta love the first bullet from this conclusion by Stephen Welby, Deputy Assistant Secretary of Defense for Systems Engineering, speaking at the AFEI Agile for Government Summit, November 21, 2013

When he says in the 4th bullet point "upcoming revisions to 5000.2", he is referring to the DoD instruction for operation of the Defense acquisition system, revised in the fall of 2013, and then revised again in January, 2015.

This latest version of the instruction describes six models of how to acquire systems, the third of which, Model 3, describes an incremental methodology that is "agile" like. Of course, there are a lot of non-development swim lanes and pre- and post- tasks, as you would expect in an organization accustomed to working at large scale.

There are, of course, a myriad of "how to" acquisition guides for the program manager. Mitre, a DoD think tank contractor, has a decent acquisition guide written in 2014.

---

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

Integrated product teams

---

The US DoD has had the concept of the Integrated Product Team (IPT) for a couple of decades.  If you search "Crosstalk, the journal of defense software engineering", you'll find zillions of articles that reference the IPT.

And, if you search www.dau.mil, you'll also find a wealth of material. As the agile folks go about with multi-functional and persistent teams, they'll find that's an idea that was mature in DoD before the agilists were organized.

Here's few important points about integrated product teams (taken from training materials produced by Space and Naval Warfare Systems Command (SPAWAR) San Diego Systems Center):

• IPTs are cross-functional teams that are formed for the specific purpose of delivering a product for an internal or external customer
• IPT’s implement the IPPD Process.  DoD defines Integrated Product and Process Development (IPPD) as “A management process that integrates all activities from product concept through production/field support, using a multifunctional team, to simultaneously optimize the product and its manufacturing and sustainment processes to meet cost and performance objectives.”

 That's all well and good, but here's where their power comes from (and agilists will be sympathetic to this list)

• (Team) must have vision or objective defined, including level of authority
• Team should be multidisciplinary
• Members must have both mutual and individual accountability
• (Team) must have a decision-making process defined
• Team members empowered to make decisions
• Cost, schedule, and performance parameters pre-defined for the team

Of course, DoD is clever enough to know that one size does not fit all. Consider these various team possibilities:

•  OIPTs (Overarching IPT)
  - acquisition oversight
• IIPTs (Integrating IPT)
  - coordinates WIPT efforts and covers all topics not otherwise assigned to another IPT
• WIPT (Working level IPT)
  - focuses on a particular topic
• Program IPTs
  - provides for program execution

Interested? You might like "How to form an IPT" in the Sept-Oct 2002 edition of the Defense "AT&L" online magazine (free). Author David Hofstadter from the Defense Systems Management College. Hofstadter tells us this:

The first step was to determine the IPTs. The program manager and his functional chiefs decided which major products or components needed direct management by an IPT.

Next they took the necessary time to carefully craft a charter for each IPT. The charter had to be specific, not at high level, not vague or timid. It had to contain milestones, outcomes, or specific objectives.

The charter had to state the IPT’s authority and the next level of reporting for the IPT. The program manager and his chiefs named in the charter an IPT lead whose responsibilities were stated, which did not include any functional responsibilities. Finally the charter was signed by the program manager. Each charter was eventually posted in the IPT’s team area

You've probably got enough to get started.

---

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

Innovation or efficiency

---

For F.W. Taylor, the scientific management guy, success was to be found in efficiency. He was the guy with the process stop watch and the job descriptions. But recently, efficiency has given way to innovation, even in PM. Traditional methods, honed and efficient, have been displaced by agile and empirical methods, not particularly efficient they are, but resilient with failure, to be sure.

WW II  and innovation
Now, it may seem that a war that ended some 60 years ago this summer is a bit distant to connect to contemporary dots. But no! WW II ushered profound changes into the culture and society of the United States that is fuel for the innovation fire.

• WW II empowered 50% of our workforce for the first time. Women entered the workforce in large numbers doing jobs never open to them before. They have never looked back
  
  WW II beget the 'GI Bill' that sent millions to college and all but invented the modern middle class from which yet more innovation, inventiveness, and entrepreneurship has arisen.
  

The scope of WW II projects was unprecedented, leading to the military-industrial complex that defined and codified program management, system engineering, risk management, analog simulation, and a host of other project practices heretofore unknown or undefined.

• WW II unleashed innovation as no other world event. The modern research university was empowered. During the war, the laboratories at MIT and CalTech and Stanford were at the forefront of new ideas, inventions, and applications. Since then, a multitude of research universities have been drivers of the innovation explosion in the United States.
• Although the war drove atomic science, atomic science drove quantum mechanics, an understanding of the sub-atomic structure. From this we have all manner of semiconductors that have in turn been the underpinning of the information age.

Throughput won the war
The enormous industrialization of WW II all but put defined process control on the map. Repeatable process and process control gave us unprecedented throughput. Who knew you could build 55K ships and 600K aircraft in four years?

And now, we have "throughput accounting" which many say is the only way to value projects: the value is in the "add", ignoring the infrastructure and permanent staff sustaining cost that gets allocated into the project overhead.

The "good" war?
It sounds like "...there's nothing like a good war".  But that's not the case.  The emergency of warfare has always raised the bar.

Before the U.S. civil war in the mid 19th century, railroads as a means for tactical support for forces was unheard of; so also electronic messaging ... the telegraph in those days ... changed not only the timeliness of reporting, it changed forever the influence of "high command" on the tactics of the moment.

What we can say:
Innovation, as a consequence of great national emergency, is the sidebar that always gets a boost.

---

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 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

---

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 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!

---

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

We don't do manifestos

---

You gotta love the first bullet from this conclusion by Stephen Welby, Deputy Assistant Secretary of Defense for Systems Engineering, speaking at the AFEI Agile for Government Summit, November 21, 2013

When he says in the 4th bullet point "upcoming revisions to 5000.2", he is referring to the DoD instruction for operation of the Defense acquisition system, revised in the fall of 2013, and then revised again in January, 2015. This latest version of the instruction describes six models of how to acquire systems, the third of which, Model 3, describes an incremental methodology that is "agile" like. Of course, there are a lot of non-development swim lanes and pre- and post- tasks, as you would expect in an organization accustomed to working at large scale.

There are, of course, a myriad of "how to" acquisition guides for the program manager. Mitre, a DoD think tank contractor, has a decent acquisition guide written in 2014. You can download a pdf here.

---

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

Agile and the U.S. DoD... more info

---

Jeff Sutherland, an agile thought leader, brings us the latest news about agile practices in the U.S. DoD, which is important not because of the military utility of agile, but for the acceptance in a large organization accustomed to strong command and control in project processes. Jeff writes:

"Since I briefed the Coordinating Task Force at the Pentagon on how to report back to the Congress on progess, we've talked a lot about how the US Department of Defense (DoD) is going Agile.

We've also shared some ideas on how to do it from SEI. Here is some real concrete guidance about how to do it from the DoD. We've also been corresponding with four-star General Barry McCaffrey, my former classmate at West Point.

He was very clear in his comments on our new book, Scrum: The Art of Doing Twice the Work in Half the Time. “Scrum is mandatory reading for any leader, whether they’re leading troops on the battlefield or in the marketplace. The challenges of today’s world don’t permit the luxury of slow, inefficient work. Success requires tremendous speed, enormous productivity, and an unwavering commitment to achieving results. In other words success requires Scrum.”

In the process of writing our online course Agile Defense we read with great interest the Interim DoD Instruction 5000.02. This document shows at least one way the DoD is thinking about doing, Agile development in software.

We also get this:

"This [new agile] model is distinguished from the previous [traditional] model by the rapid delivery of capability through several limited fieldings in lieu of single Milestones B and C and a single full deployment.

Each limited fielding results from a specific build, and provides the user with mature and tested sub-elements of the overall capability. Several builds and fieldings will typically be necessary to satisfy approved requirements for an increment of capability.

The identification and development of technical solutions necessary for follow-on capabilities have some degree of concurrency, allowing subsequent increments to be initiated and executed more rapidly."

---

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

Large Scale Agile

---

I think this cover says it all. Large scale agile is a bit of a high wire act, but doable.  So we read in the May/June 2013 issue of CrossTalk, the Journal of Defense Software Engineering.

(Full disclosure: when I decided to write a book based on my agile experience, I chose to write about agile in the enterprise: "Project Management the Agile Way: making it work in the Enterprise")

The lead article, "Scaling Agile Development" is by authors Craig Larman and Bos Vodde, the former known best for his 2003 book: "Agile & Iterative Development" but more recently for a two volume tome about scaling agile, from which this article is developed.

(Another disclosure: I've not read any of Larman's books; only this article)

In a word or two: OMG, No!

At best Larman and Vodde are examples of agile naivete; at worst, they're just plain wrong headed about how to do agile in the defense industry. And, it's a shame that Crosstalk, a worthy journal to be sure, but obviously not peer-reviewed, would publish such a poorly conceived paper.

Their basic idea is this: Agile, in the guise of Scrum, is scalable to any limit -- thousands of developers they say -- by the simple expedient of adding teams (in 10 person increments) and adding some coordination meetings and tools. Architecture, testing, and management -- unneeded they say except for that which a team can provide for itself -- are unnecessary burdens, even for huge projects.

They posit that all this is doable in three frameworks: First the single team for the small projects; second a framework that does for 10 team (100 team members); and then a third framework that is unlimited in its scalability. The differences in frameworks are some overhead services provided at each level for coordination and communication and management of the project-level backlog, and the idea that at the framework 3 level more than one product owner will be needed, and so a committee of product owners will be needed. Indeed, most of the discussion centers on the backlog and how it is to be distributed among teams.

At scale, for many skills, like architecture, the authors suggest the benefits of a "community of practice" birds-of-a-common-feather organization plan (I like this idea and it's generally endorsed in the agile large-scale community).

I also like some of their ideas about organizing the backlog -- which at scale will be tens of thousands of stories, etc -- into "areas", like protocols, but NOT into such broad categories as "performance".

There's no discussion of how these frameworks fit, or could fit, in a contractor/government environment; how the warfighter's interests are to be represented... they certainly aren't present to be the product owners; and how processes that obviously breakdown at scale -- like simple war rooms with sticky notes for stories -- would work with tens of thousands of stories. And, there's no discussion of interfaces to legacy installed base; no discussion of working through defined interfaces or APIs; and no discussion of how other swim lanes (or WBS verticals) would be brought into the project.

Even worse in some respects, given the need to honor "other people's money", there no discussion of a business case or how to present large-scale agile in a business case.

All the method discipline of XP is ignored; all the great practices of agile modeling and scaling, so well documented in the agile DSDM methodology and by such practitioners as Scott Ambler who has made a science out of agile-at-scale is ignored in favor of the lightest weight and least demanding of the agile methodologies: Scrum

In short, if these two guys have ever been close to a large scale agile project for real, it does not show. If they have ever tried to build programs and projects for the defense industry, whether business systems or warfighter systems, it is certainly not in evidence.

For more of my thinking on agile in the DoD, read this white paper. (Yet again, another disclosure: I worked for the DoD as a project manager and I worked for the DoD as a contract project manager doing software systems development). And, for agile in the waterfall: this posting.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Defense AT&L and Agile

---

The cover article in the January-Febuary 2013 (free online) issue of Defense AT&L is about agile in the DoD as a consequence of the 2010 U.S. Defense authorization mandating agile.

The article's theme is "terra incognita": "... new territory, full of unfamiliar processes, lacking clear alignment to existing expectations..."

Unfortunately, this article is long on issues and short on actionable practices for the contracting officer, acquisition officials, and contractors.

This figure more or less captures the essence of the author's points, which is a relocation of requirements in the traditional alignment. The article is somewhat based on Leffingwell's well received book: Scaling Software Agilility.

Striking contrast
What really caught my attention was another article in the same issue  (Good contacts start with good requirements by Eesley) about fixing requirements early and firmly, the very thing eschewed in the cover article.  Of course, to be fair, all DoD programs are not software intensive, and so all DoD programs can't take full advantage of agile methods.

Nevertheless, a search of 'Good contracts' on the word 'agile' returned no hits; thus this article didn't seem to acknowledge the requirements paradox, which in part drives agile:

• We always want requirements to be stable to drive design and development; but user requirements are never stable enough to drive design and development.

And, 'Good contracts' didn't acknowledge the move from 'shall' and 'will' to the conversational mode of agile, where the capture mechanism for the conversation is a test script and not a requirements statement per se.

At some point, the dots will connect better than they do, but there's a long way to go. For more on my ideas, see:

Agile and the DoD from John Goodpasture

 

---

Bookmark this on Delicious

Cyber security journal debut

---

In October 2012 the inaugural issue of the Cyber Security and Information Journal made it's debut. Online, it came out mid-December.

The opening article describes the U.S. Air Force's Cyber Security and Information Systems Information Analysis Center - CSIAC

We learn that "CSIAC is chartered to leverage best practices and expertise from government, industry, and academia on cyber security and information technology. Operating in an agile manner, the CSIAC will monitor and utilize emerging technologies of information assurance, software technology, software and systems engineering, modeling and simulation, knowledge management and information sharing."

You can't miss the word "agile" that, if anything, is a loaded idea, especially in the DoD. But since this quote came from a contracting officer, Paul M. Engelhart, one can only hope that general approach of agile in the U.S. government is in play.

There's an interesting article on software reliability, something that has wide interest and application all across the apps industry, whether mobile or traditional web. We're told:
 

Software reliability is defined as

the ability of a program to perform a required function under stated conditions for a stated period of time. Quantitatively, this may be considered as “the probability that software will not cause the failure of a system for a specified time under specified conditions.

An unreliable software-based system may be unavailable, incorrect, vulnerable, or possibly even unsafe. This variety of inadequacies and failure modes includes both “sins of omission” (not behaving as intended) and also “sins of commission” (behaving in unintended ways).

And, in a bit of inside-the-beltway infomation, who knew there is a Department of Defense (DoD) Electronic Biometric Transmission Specification (EBTS), and even more curious, who knew there is a Biometrics Identity Management Agency (BIMA). You can't make this stuff up; and where else can you read about it?

 

 

 

---

Bookmark this on Delicious

Integrated Product Team (IPT)

---

The US DoD has had the concept of the Integrated Product Team (IPT) for a couple of decades.  If you search "Crosstalk, the journal of defense software engineering", you'll find zillions of articles that reference the IPT.

And, if you search www.dau.mil, you'll also find a wealth of material. As the agile folks go about with multi-functional and persistent teams, they'll find that's an idea that was mature in DoD before the agilists were organized.

Here's few important points about integrated product teams (taken from training materials produced by Space and Naval Warfare Systems Command (SPAWAR) San Diego Systems Center):

• IPTs are cross-functional teams that are formed for the specific purpose of delivering a product for an internal or external customer
• IPT’s implement the IPPD Process.  DoD defines Integrated Product and Process Development (IPPD) as “A management process that integrates all activities from product concept through production/field support, using a multifunctional team, to simultaneously optimize the product and its manufacturing and sustainment processes to meet cost and performance objectives.”

 That's all well and good, but here's where their power comes from (and agilists will be sympathetic to this list)

• (Team) must have vision or objective defined, including level of authority
• Team should be multidisciplinary
• Members must have both mutual and individual accountability
• (Team) must have a decision-making process defined
• Team members empowered to make decisions
• Cost, schedule, and performance parameters pre-defined for the team

Of course, DoD is clever enough to know that one size does not fit all. Consider these various team possibilities:

•  OIPTs (Overarching IPT)
  - acquisition oversight
• IIPTs (Integrating IPT)
  - coordinates WIPT efforts and covers all topics not otherwise assigned to another IPT
• WIPT (Working level IPT)
  - focuses on a particular topic
• Program IPTs
  - provides for program execution

Interested? You might like "How to form an IPT" in the Sept-Oct 2002 edition of the Defense AT&L online magazine (free). Author David Hofstadter from the Defense Systems Management College. Hofstadter tells us this:

The first step was to determine the IPTs. The program manager and his functional chiefs decided which major products or components needed direct management by an IPT. Next they took the necessary time to carefully craft a charter for each IPT. The charter had to be specific, not at high level, not vague or timid. It had to contain milestones, outcomes, or specific objectives. The charter had to state the IPT’s authority and the next level of reporting for the IPT. The program manager and his chiefs named in the charter an IPT lead whose responsibilities were stated, which did not include any functional responsibilities. Finally the charter was signed by the program manager. Each charter was eventually posted in the IPT’s team area

You've probably got enough to get started.

 

---

Bookmark this on Delicious

Agile and the DoD (again)

---

David F. Rico has a presentation about Agile in the DoD. He presents a compelling case for agile in large scale systems and in enterprises steeped in traditional methods, and those highly regulated for quality and compliance to standards.

There is both a video of his presentation, and a slide set. You can get all the details for accessing the video at Herding Cats. Once you're into the video, you can click on the right-side panel for another window to open with just the slide set.

---

If you're interested in other perspectives, search for 'agile' in the online journal for DoD software engineering "Crosstalk"; there are dozens of good articles there on DoD projects and process.

---

Another summary of things going on is given to us by Jeff Sutherland on his "DoD goes Agile" posting. He (Jeff) quotes from the 2010 Defense budget authorization bill:

The key language is this:

(2) be designed to include—

(A) early and continual involvement of the user;

(B) multiple, rapidly executed increments or releases of capability;

(C) early, successive prototyping to support an evolutionary approach; and

(D) a modular, open-systems approach.

Basically, for the DoD at least, Agile became the law. Here's the report the DoD returned to congress

Or, for my perspective, you can read here or below:

Agile and the DoD

View more documents from John Goodpasture

Bookmark this on Delicious

Voice of the customer

General James F Amos, Commandant of the US Marine Corps, has taken on the acquistion bureauracy since assuming command of the Corps.

At issue: favored acquisition programs for modern weaponry for the Marine Corps, and to some extent, a rescue of the Marine's mission, now under fire as an unncecessary second land army.



So, when I see in a recent interview where Amos says that he had appointed himself player-coach (his phrase) on a number of troubled projects, I had to read further.

A couple of his thoughts that caught my eye:

 Math decisions are easier than thoughtful decisions based on strategy and what's best for [the mission]

[To his professional acquisition team]: You're telling me it will take 14 years to get the requirements right, develop this thing [a new amphibious vehicle], source select, test, and then field initial capability? You're crazy!

And of course he's right: if we've waited 14 years for major solutions, like the mine resistant reconnaisance vehile developed for Iraq, we'd be five years yet getting it.

Perhaps General Amos should take a page from USAF General Bernard Schriever, the father of modern program management and system engineering, who, the post war 1950s, pretty much invented how to do military weapons programs (the exception being the WW II program for the 'bomb', a program that Schriever did not participate in). In a recent book, "A Firey Peace in a Cold War: Bernard Schriever and the ultimate Weapon", by Neil Sheehan, General Schriever's acquisition methods are explained in a great tale of the Cold War.

His idea is to put system engineering on the front burner, work quickly with prototypes, develop high risk ideas with multiple concurrent solutions, drive hard for the initial operating capability, and don't let better defeat good. In other words, don't let strategy, or strategic purpose starve innovation. Be prepared to accept opportunity as perhaps a better way.

Perhaps, Schriever was the original agilist!

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

More on Agile and the DoD

Close upon the heels of PMI's announcement of their embrace of Agile, the US DoD is stoking the fire as well, evidenced by the industry conference in April, to wit:

According to their marketing release:

Why Attend —The Value Proposition

Agile development and test will improve DoD’s acquisition of IT applications leveraging cloud computing and service oriented architectures used by information sharing applications such as collaboration (strategic and tactical intelligence) analysis, ISR sensor “fusion” processing, coalition and joint tactical operations, logistics and sustainment support, transportation functions, geospatial and decision support apps, medical or health care record sharing, etc.,).

The new paradigm is significantly different and should not be confused by today’s spiral development process. Agile sprints are comprised of (smaller line-of-code) projects, month not years time driven release commitments with integrated development, operational, interoperability and user acceptance testing.

Once implemented, DoD user approved requirements tailored for each sprint (vice large Requirement comprised Major Programs of Record) will create a new “partnership” relationship amongst industry and government users, developers and testers.

Yea verily, and press on!

Of course, I'm not an unbiased commentator.  I've written a book on agile in large scale organizations, and I've written papers on the topic of DoD and Agile.  I've worked as a Program Manager within DoD, and as contractor for DoD.  So, count me among those who hope their initiative succeeds.

Todd's Tech Bites -- Agile Methods

View more webinars from John Goodpasture

  Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Grady Booch on DoD software management

Back to this month's "Crosstalk" that is the issue on architecture. This issue also has an interview with Grady Booch, now with IBM but probably best known as one of the three main authors of the Unified Modeling Language, UML. [Historical note: IBM bought Rational a few years ago, and Booch was a key guy at Rational inventing UML]

Booch gave his opinion about the DoD software community:

It really used to be, decades ago, that the DoD was leading the marketplace in the delivery of software-intensive systems. The harsh reality is that the commercial sector is leading best practices and really pushing the arc relative to software engineering and software development. So, in that regard, the DoD is behind the times. That is not to say that they are not pushing the limits in some areas. The kind of complexity we see in certain weapons systems far exceeds anything one would see commercially, but ultimately, there are a lot of things that the DoD can learn from the commercial world.

I wonder if the commercial "best practices" he refers to are Agile, or something from the CMMI? I'm not sure I would put Agile under "best practices" for general development, but certainly for cases of evolving and emerging requirements that are not fixed in anyone's mind, Agile is a risk management solution for that dilemma.

And, I certainly wouldn't call Agile "software engineering". Test driven design--TDD--might qualify as an engineering practice, so also refactoring, but most of the rest of Agile is management not engineering.

Those are my opinions. Booch had something different to offer:

Three recommendations for large scale organizations

Booch has three recommendations for DoD software managers and practitioners, but really these apply to any large scale organization doing software intensive systems:

1.  Increase leverage of open-source tools and resources. This is not just a cost issue; it's an issue of leverage for innovation and transparency.  Specifically, Booch says push 'Forge.mil' along, the services arm of 'SourceForge'

2.  Build more elaborate and deployed infrastructure for collaboration. [I think he means: It's not that programs should be managed from Facebook or Twitter....they shouldn't...] There should be more emphasis on leveraging the worldwide expertiese of DoD and its contractors

3.  Go beyond functional modeling and get down to modeling the system itself.  Make architecture an artifact of the project. To this, I say: Amen!

The DoDAF [DoD architecture framework] as a means to bring more emphasis and utility of architecture to DoD programs. Booch thinks DoDAF is effective for modeling the 'enterprise of the warfighter', but is less effective in modeling software intensive systems.

Perhaps so. However, the DoDAF is certainly in evidence in the battlefield robots now under development and being deployed. We'll see how that works out. Advantage: USA [for now]

 Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Crosstalk reviews architecture

"Crosstalk" has a new online website that presents the magazine in a truly online format. I personally like the "flip through the magazine" functionality....a really easy way to see the whole issue quickly.

Architecture

This month's edition is dedicated to architecture, ordinarily the domain of system engineering, but a discipline I firmly believe PM's should embrace as necessary in every project.

Why?

Architecture is the arching narrative that pulls the whole WBS together. And since the WBS is the object of the schedule, architecture helps to integrate all the project pieces. Architecture is an abstraction of the WBS;  its that level of detail that's usually of interest and important to sponsors, stakeholders, and beneficiaries .... therefore, it's important to PMs. 

And, here's the clincher for me: architecture plays directly into risk management.  To see why, consider these properties of architecture:

Topology and protocols:

Architecture tells us the topology of the system, product, or process. Topology tells us about hierarchy, interconnectedness, and whether nodes are reached by point-to-point, hub-and-spoke, or some mesh circuitry.  In some cases, architecture gives the protocols, that is: the rules, by which elements of the system tie together.  Architecture gives form to requirements. 

Cohesion, coherence, and coupling:

Cohesion is a measure of "stickiness", the degree to which elements of the project outputs will hang together under stress, work together well in the environment, and not do chaotic or disparate things when stimulated differently.  Good cohesion is good and lowers risk.

Coherence is a measure of sympathetic reinforcement.  Coherence gives rise to the adage: "the sum is greater than the parts".  High coherence is generally good and lowers risk

Coupling is a measure of interference or dependency between units, subsystems, and modules.  In general good architecture respects natural boundaries; disrespect leads to strong coupling and propagation of errors, stress, and failures.  Loose coupling that traps effects before they propagate to other components is generally good, and lowers risk.

Summary: pay attention to architecture!

 Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.