Project Management

Facilities Management

Agile Project Management – Task Collaboration

Our Product is Steel…Our Strength is Our People.  That’s a slogan coined by Defasco back in the 1970’s.  Since then, several corporations have developed a corporate focus in their respective mission statements  based on customized variants of this famous slogan.  It’s clear that “the people” form the fabric of any company; therefore, their ability to collaborate effectively underpins the mechanism by which individual contribution is summed up to form the value position of the company. It’d be fair to say that most folks would whole heartedly agree with this statement, and would endeavor to believe that simply putting the right people together will cinch this secret formulation to achieve greatness. When looking at corporate practices, this formulation is often thought to be solely based upon an individual’s core characteristic criteria.  Upon establishing the fundamental characteristics possessed by the individual, such as during the interview process, then a subsequent assessment of the chemistry that exists between individuals (i.e. those working together) form the bonds that produce the “Strength” formula as stated by Defasco in their slogan.

For many companies, the essential collaboration mechanism is thought to be the automatic result of good team member choice in the same way that a great culinary masterpiece is a mere product of the recipe’s ingredients.  This is not to say that a great leader is just another selection along the same lines. There’s no contest or debate on the importance of leadership; hence, the Project Manager’s (PM) role to lead the team successfully (as measured by one form or another of earned value) is highly dependent on the very strength of the people.  The fallacy that can and does trip up the PM is that task collaboration is automatic if the belief is that individual intelligence and interpersonal characteristic chemistry are the only two ingredients.

Collaboration is and has always been thought to be a result of assembling the team at the designated brick & mortar office location. Of course, if you believe in the formulation mentioned earlier, then you’d pretty much have to insist that a project team would have to be collocated in order to have any change of tapping into the strength formula.  The big mistake here is to think that the leadership direction will automatically blend into the team’s membership daily activities in exactly the right balance in order to achieve the desired output.  It has been my experience that collocated teams foster a foundation of tribal knowledge as the basis of their daily execution; hence, tend not to engage in any form of task formalization.  This loose form of collaboration is more of a hindrance when it circumvents the application of a structured framework. In my experience, it is often specific groups within organizations that resist structured collaboration.  These groups will also resist the recognition of task collaboration.  Agile, as a framework, is one of the systems being successfully implemented that augments the intelligence ingredient creating an even more powerful library of tribal knowledge.  When applied in conjunction with currently available technology, this powerful collaborative environment minimizes the collocation “curse” in that it enforces a much more succinct form of communications in the form of written comments in place of in situ conversation.  Having a permanent record provides all members of the engaged team the benefit of the conversation thread.

Agile Project Management is the management of the full suite of groups forming the wide project team.  Many companies are organized as matrix organizational structure of one type or another, with each functional group having their unique processes.  It is rare to find a case where the wide team contributors from Sales, Marketing, Finance, Manufacturing, Quality, Technical, etc are of a unified vision or mission in regards to the project.  Each of these groups will operate in their own circles using their own processes to collaborate amongst themselves. In larger organizations, these various group are often not collocated and have several ventures on the go at the same time.  As human resources to the project are essential, it is critical to ensure that task collaboration is managed across the entire project.  Task management must be proactive, which means that all contributors must primarily contribute by way of producing task results in the form of tangible deliverables. This must start by recognizing these deliverables on the Work Breakdown Structure (WBS).  Effective collaboration is both an open forum general communications as well as planned time correlated communications.  As a PM, a key ingredient for successful task collaboration is to structure the known issues (i.e. write them down in the form of Epics and Stories) and plan for the communications in a sensible coordinated fashion.  This is especially important for fractional team members because you likely will not have impromptu access to their undivided attention on an unstructured basis.

In conclusion, successful task collaboration must accommodate and take advantage of the strength of the people.  Considering that several distinctly different disciplines are involved in most projects, the PM must recognized that one size does not fit all.  A delicate balance of planning the high level “big rock” tasks (Epics and Stories) early in the project is the right thing to do.  Trying to sequence every last detail early in the project is not productive and almost always leads to contention and wasted effort.  Agile Project Management plans for the boundaries upon where the team can effectively operate, and plans for handling dynamics as opposed to predicting the specifics of the daily battle.


Agile Project Management – Project Kick-Off

Project Kick-Off is more often than not treated as a joyous announcement to the organization and the Stakeholders that a project is recognized from this day forward as official.  There might be a catered meeting call, and a few words of encouragement about the project goals or the diligence of the business team to sign an agreement with a key customer.  The intent and purpose of the event usually stops there often having been an adhoc impromptu announcement notice with little forethought or planning to actually get the project started.  A Kick-Off announcement is often thought of as a call to pull out the golden scissors to cut the ceremonial ribbon on a newly signed contract; hence, the event is actually denoting a completion of a phase as opposed to the beginning of a project.  The Project Manager (PM) often receives the meeting invite at the same time as the wide team and stakeholder’s; therefore, the PM is just an attendee and not the organizer of the Kick-Off of the project.

It is very important that the PM gets out in front of the Kick-Off event to ensure that the project is fully ready to go green.  This means that preparations are completed prior to the Kick-Off event to ensure that the following key metrics are clear and are underpinned by a specific plan:

  1. Team Assignments
  2. Recognized Stakeholder’s
  3. Project Deliverables
  4. Key Performance Indicators (KPIs)
  5. Key Milestones

These five metrics are not the complete list, but do represent a foundation for the announcements that are advertised at the Kick-Off event.  In order to publish “public domain” summaries for each of these metrics, a decent straw man plan must exist in order to build out the detail of the project.  The last thing that a PM needs is to attend a meeting like this to find that the Senior Management Team (SMT) or the designated Product Manager (PdM) makes statements about these metrics based on wishful data that they may have just pulled out of their ass.  The PM must get out in front of this by setting a clear standard for the kick-off.  The best way to do this, is to have a check list that is endorsed by the key stakeholders.  The artifacts prepared by the PM (and his designates in the case of a larger project) must be complete and agreed upon by the stakeholders in order to have a unified and clear goal, and that the expectations are in line and achievable.

From an Agile Project Management standpoint, the execution of the project must be clearly tied to the structure developed for the kick-off.  The short term team engagement in the project may be limited to assigned team leads and system planning in order to ensure that the requirements and expectations are derived into language that the team can understand at an execution level.  The Work Breakdown Structure (WBS) must be defined prior to the kick-off, and must be deliverable centric as opposed to a project organizational chart or an activity chart.  Item number 3 above is the high level presentation of the WBS.  This not to say that every last WBS element is finalized, but must be built out sufficiently to validate budgeted metrics.

Is the kick-off the all-call for the wide team to jump to action?  Absolutely not! The wide team cannot jump aboard the project as if it were a cruise ship leaving port because the plan will not be mature enough to direct the low level detail.  The team leads must first distill the straw man plan.  Even at the best of kick-off preparation intent, the detailed tasking backlog preparation will be performed immediately following the kick-off; not prior to kick-off.  The kick-off preparation must focus and limit the planning to a high level sufficient to structure execution detail laid in thereafter.  In short, the kick-off needs establish structure and does not need to be nor should ever be a detailed playbook for immediate execution.  The best way to gain a clear understanding of a project kick-off would be to document the expectations and to establish the check list so that the right level of detail is undertaken.

Agile Project Management-Requirements Management

Requirements Management is one of the most mistreated and misunderstood knowledge areas in Project Management.  In my professional practice, I experience the full spectrum of functional requirements management  styles and opinions.  In most cases, client’s will make their best attempt to extract some form of written requirements at the onset of a project to put some shape on the estimates for the job (for lack of a deeper purpose).  These written requirements are more often than not just published on a project wiki page, and are often open ended statements that are indistinguishable from a stakeholder expectations log.  This “publication” is often a onetime posting that is not maintained throughout the project cycle.  This practice is very prevalent among the clients that declare they are operationally “Agile”.  At the other end of the spectrum, clients who operate in industry sectors demanding regulated product assurance standards elaborate and formally release requirements documents, but fall short when it comes to adequately managing these requirements.  This practice is very prevalent among the clients that declare they are operationally “Certified” in accordance to their respective regulatory standards.

For many of the self-proclaimed Agile clients, they are really using the word (agile) to distinguish themselves from the other end of the spectrum.  They tend to refer to written requirements as the nemesis of dynamic creativity; hence to formally commit to such a written list would completely limit the final product.  This is a completely distorted view of agility and is completely misaligned to the practice of Agile Project Management.  The ability to be truly agile is to be open to change and to manage change in a structured fashion.  Requirements form the frame upon which the final deliverable(s) is structured.  Having these requirements documented in a way that facilitates a visual mapping breeds creativity.  This mapping, when correctly structured, forms the basis of the epics and stories which are the foundation of the agile framework.

As for the other end of the spectrum, documented and formally released requirements are more often than mismanaged because of the following reasons:

      1. Incorrectly or completely uncategorized listing of singular statements
      2. Buried or nonexistent traceability to lower tier requirements and specifications
      3. Loose or nonexistent relationship to ancillary applicable documents
      4. Loose or nonexistent relationship to derived requirements (orphans)
      5. Loose or nonexistent relationship to formalized change orders
      6. Loose or nonexistent relationship to deviations and waivers
      7. Loose or nonexistent management of TBD’s and TBC’s
      8. Loose or nonexistent relationship to stakeholder expectations
      9. Uncontrolled dissemination of requirements change to the wide team
      10. Incorrect connections to the Risk Register

Believe it or not, I see all of these key violations in the high reliability sector. I have listed the association to the Risk Register last because it is both a reason and a resulting case of collateral damage.  As I have mentioned in previous blog posts, risk adverse clients transfer these issues into risk, and proceed to claim hold harmless status thereafter.  This happens because the Requirements Management Plan does not address how to handle these issues.  The management of requirements is simply transferred to the Systems Management Plan, and the Project Manager completely lets go of this critical part of overall project leadership.  This is real mistake on many levels.  At the top of the list is the impact on Change Management.  I have yet to experience (going on 30 years in this business) a top level requirements document being “static” and not subject to change.  The requirements always change.

Agile Project Managers must take charge of Requirements Management.  There is a distinct segment of the defined responsibilities in the execution of requirements management that falls into the Systems Team’s scope of control.  Certainly capturing, clarification, and interpretation of customer requirements clearly falls into the Systems domain.  This must include clearly derived TBD’s in lieu of customer’s future clarifications.  In cases where the stated requirements are on the light side, (the “Agile” case I mentioned earlier) the Project Manager must endeavor to back fill these requirements with stakeholder expectations and derived requirements in order to set a clear and complete visualization for the team.  This must be defined and well-rounded prior to kicking off the project.  All work effort and non-labor spend during execution must clearly tie back to the requirements.  This definitely must be a section in the execution playbook because the requirements visualization is the hitchhiker’s guide to the galaxy®.  All successful teams rely on a strong playbook!


Agile Project Management – Risk Management

Risk Management tends to take on one of two states in most companies, and as you may suspect are polar opposites.  There are the risk adverse who are fear centric, and the risk oblivious who are….. well just oblivious.  Both of these operating states are very common in my experience.  Based on my own client experiences, I have only come across about 3 or 4 out of 10 clients that have a healthy view of risk in that they recognize the value of good risk management and actively engage all levels in the corporation in risk awareness.

Let’s start with a top down view of a project from the standpoint of metrics and look at how risk may impact each.  At the highest level, the triple constraint evaluates three cornerstone aspects which holistically defines a project and establishes a scalable interaction between the three constraints.  These constraints are:

  1. Scope
  2. Time
  3. Cost

Scope Identified Risk

Scope identified risks should be the easiest to define if the Program Management Plan has a well-defined Scope Management Plan section and a well-defined Scope Baseline.  The risk of a scope change can thereby be restricted to To Be Determined (TBD) or To Be Confirmed (TBC) requirements that were loosely defined at the onset of the project.  This statement may draw some rebuttal, but please read on.  It is understood that the Statement Of Work (SOW) will not reasonably capture all explicit requirements that clearly define all deliverables; however, the derived requirements that were defined by the proposal team form part of the project requirements.  These additional requirements must be clearly stated and captured as part of the official input to the Project.

Time Identified Risk

Risks captured to identify impact to timeline must distinguish a specific tie to schedule.  These are sometimes difficult to distinguish separately from cost, therefore are often combined.  In some cases, the risk may identify a third party service or deliverable that may drive out schedule.  Availability of key resources, or an underestimation of due process could also be fair game here.  Another example may involve a multi-prong development of design options in order to hit specific recurring cost targets.

Cost Identified Risk

Risks captured to identify cost can identify either/or specify costs to execute the project or cost targets for the deliverable in cases where either the expectations or requirements specify this parameter.

Define a Corporate Risk Register Template

When constructing a risk register, there are both guidelines and rules that must be applied in order to build a purposeful risk management process.  Developing a corporate risk register template is very important in order to develop consistency for effective and efficient collection of contributions, ongoing management, and portfolio comparison evaluation.  A risk register must provide a qualitative assessment of project risk.  Qualitative assessment involves two main metrics to establish the probability and impact of each stated risk.  These two main metrics influence cost and/or time against the deliverables defined in the Work Breakdown Structure (WBS).  Each risk will define an Unfactored Cost which sets a Rough Order of Magnitude (ROM) amount.  The Probability defines the likelihood, and sets the calculated Factored Cost amount.  The Impact is a scaled number to categorize the severity of change which usually plays out as a timeline and/or deliverable configuration change.  The risk register must capture a clear impact statement to define the WBS element that is impacted.  In the event that a given risk is realized on a project (i.e. the probability increases to 100% or a pre-set corporate threshold), then this risk is incorporated into the project baseline through a Project Change Request (PCR), and is thereby entirely or partially retired from the risk register.  It is very important that a well-defined identification tagging is established.  In short, here are the minimum recommended risk register fields that need to be identified:

  • Risk ID
  • Risk Title
  • Risk Description
  • Update Date
  • Estimated Start Date
  • Estimated Expiry Date
  • Owner
  • WBS Element Affected
  • Probability
  • Impact
  • Unfactored Cost
  • Impact Breakdown Definition
  • Risk Strategy (ex. Watch/Mitigate/Accept/Transfer etc)

Define Allowable Risk Rules

As far as rules are concerned, the most important rule is that all captured risks must be clearly outside the risk owner’s scope of control.  As a secondary caveat, the risk should also be approved by the Project Manager (PM) before it is officially logged on the risk register.  Another rule that must be established is regarding the category of risk allowable for the formal risk register.  There are three categories of risk as follows:

  1. Known-Known Risk
  2. Known-Unknown Risk
  3. Unknown-Unknown Risk

The first category entails risks that the team knows exist and also knows or has evidence of the existence of that risk.  An example of a Known-Known may be the availability of an internal resource that is conflicting with a known higher priority company project.  Another example may be a foundation development tool that has a known bug that affects the quality of the supplied results.  Known-Known risks are valid.

The second category is likely where most risks will be documented.  These risks will identify challenges in achieving the requirements as defined.  Likewise, the risk register also captures opportunities which would represent the converse situation for a given risk description.  Let’s say that a requirement states a specific performance parameter that is assessed by the project team as over-stated.  If the project is structured to meet operability, then an opportunity could be captured to allowably relax that requirement.  If the cost/time is tight, then it would be captured as a risk. Known-Unknown risks are also valid.

The third category of Unknown-Unknown risks must be avoided.  These types of risks are more often than not based solely on fear and are always situational circumstances that are above the proposer’s pay grade.  The PM must handle proposed risk that falls in this category delicately because team members that identify with these types of stated risks often lack confidence in general.

An important rule is required to set boundaries and thresholds for total risk and individual risk dollar amounts.  There must be an established total risk budget.  For risk adverse companies, the risk register can easily tally up a budget that can work itself to a high percentage of the overall originally estimated project cost.  Individual risk thresholds must be established to ensure the most appropriate strategy is applied.  For example, it should be unacceptable to carry a high value risk as a Watch strategy.  These must be Mitigated and should have a fully developed quantified plan in place that is invoked when the probability trips a pre-determined threshold.

The last rule to set is the cadence for Project Risk Review.  Depending upon the size of the project and the dynamics, the risks must be formally updated to ensure each are current, and that the dates and assessed metrics are correct.


In conclusion, a company must develop a Risk Management Plan that objectively sets a conforming standard by which the risk processes are executed. All too often companies fall into one of the two polar opposite regimes I mentioned at the beginning of this blog post.  Fear based risk management can provide the optics of risk management control, but are easily invalidated if the proposed rules are applied.  As for the risk oblivious, the definition of Agile Project Management may need to be evaluated.  Agility and Risk Management are two essential ingredients to any successful Project.

Agile Project Management – Change Management

The topic of change management has taken on a new meaning in many organizations.  The Agile framework mindset is very much a structured embodiment of a system that is foundationed on the dynamics of change.  The issue that I find is that the dynamics of change, in the proper sense, often don’t distinguish between the three main instigators of change being:

  1. Customer stakeholder(s) driven new or modified scope
  2. Internally stakeholder(s) driven new or modified scope
  3. Risk driven scope

On first review of the three instigators, one may conclude that risk driven change, that is to say, change that is captured on the project risk register, may identify customer and/or internal scope change as a risk.  Isn’t risk part of items 1 & 2?  My response to that is that future scope change driven by stakeholders falls into an unknown-unknown which should trigger an amendment to either or both of the Charter’s Statement Of Work (SOW) or certainly the identified and documented requirements for the project.   This is not a risk that can be quantified.   I’ll have more to say about risk management in a future blog post.  In short, a noted risk stating that the Customer or a Senior inter-company stakeholder may someday change the scope is not worthy of considering.  The risk driven change that would be considered are TBD’s in the requirements, optimistic estimates (threats), or pessimistic estimates (opportunities).

Agile framework organizations that have become obtuse via an abandonment of waterfall structured management tend not to formalize change management as it is thought to just be part of the job.  Often the formalization of requirements is thought to be either unnecessary or impossible (yes….I’ve actually had clients that have used this word) on the basis that the requirements are a result of the design; not the driver of the design.  Setting this notion aside for a moment, Agile Project Management must have cost and schedule budgets, well defined goals (i.e. scope), and well defined gating framework to adequately assess progress.  Change affects one or more of these cornerstone triple constraints which will hit the bottom line.  If Agile Project Management is ever to be confused with an environment of organized confusion, then change will most certainly be mis-managed if not entirely missed altogether.

A correctly executed Agile Project Management system will capture a change instigator upon the onset of a change and will document its occurrence, its source, and its circumstances for the purpose of tagging and tracking.  Some corporations use a formalized Change Request (CR) system, which is the first step towards adequate change management control.  The CR, as a standalone change identification is only a first step because it does not immediately identify which Work Breakdown Structure (WBS) elements that are impacted, and does not identify which requirements are added or impacted.  As the CR matures, the change in scope can rapidly infiltrate the working levels such to the extent that daily work scope can prematurely commence the process of incorporation prior to the project’s formal acceptance of the change.

If the CR is a type (1) change (i.e. Customer driven), then an assessment of the triple constraint must be immediately formalized in order to obtain stakeholder buy in.  This absolutely must precede the team undertaking the incorporation process into the tasking backlog or even worse being catapulted to an expedited task status.  The key takeaway here is that the PM must act quickly at the first sign of change to document, contain, assess, and approve or reject the change.

Once the CR is approved, the impact on cost, schedule, and scope must be formally captured.  The WBS must first be examined and adjusted depending upon the scope of the change and the contract type applied.  If the scope change alters the deliverable configuration, then the WBS must change.  If the contract type is Time & Materials (T&M) and the change is via a separate contract (i.e. not an amendment to the current contract’s Limit of Expenditure (LoE)), then the WBS must also change.  I’m always dumbfounded to come across a company’s business model that silo contracts for each incremental change, but it happens.  The PM must be able to organize the WBS to accommodate these situations while being fully cognizant of the ensuing impact that this WBS structure will have on the team performing the work.

In cases where multiple changes (CR)s are being incorporated at the same time, and cost traceability needs to be maintained for each, it may not be necessary to set up a brute force WBS element for each CR under each primary impacted deliverable.  In these cases, the PM can establish clear cost reconciliation by simply tracking low level task completion data and applying the metric time stamp for each completed task as proxy for timecard actuals would have been charged by each team member.  This, of course, will require tasking assignments to be traceable to each CR.  This really should not be a problem if the technical lead has done their planning correctly and is executing in a structured methodic fashion.  The team executes work to complete tasks that are pulled from a backlog created by the Technical Lead.  As far as the accuracy is concerned, the use of the metric time stamps in lieu of time card actuals can be factored based on earned value variances and/or cycle time tracking.  This can be very accurate.

Considering the alternate brute force WBS approach, the PM would have set up separate WBS elements for each CR under each impacted deliverable.  In order for this method to be successful, each team member would need to diligently charge their time to the correct charge number assigned to each CR for each performed task.  This would often result in inaccuracies due to juggling of charge numbers with the added artificial inflation due to rounding (many companies set 15 minute time tracking increments).  Just rounding alone can inflate daily time tracking by 45 to 120 minutes per day per person.

From a work standpoint, the executing team must first create a skeletal draft of the new or modified project requirements change such that all levels of the traceability hierarchy are clearly identified for impact.  Setting the skeleton will permit early start at all levels minimizing the serialization effect.  Each of the requirements are distilled into tasks and sub-tasks, each of which has a predetermined traceability to the CR that instigated the change.  The team can seamlessly accommodate the change traffic even in cases where the change is disruptive to current work in progress due to an alteration of a feature, physical attribute, or performance.  The PM must resist simply dumping a CR on the table and letting the team at it.  This approach is often confused with bureaucratic elimination.  This kind of Project Management is not Agile in any sense, and will likely lead to strong arm tactics like tear gas and rubber bullets to restore order.

Agile Project Management – Earned Value Management

From a business enterprise and senior management standpoint, everything that moves and breaths bears a cost to the company.  Whether the shareholder structure is privately owned, co-cooperatively owned, or publicly traded, the basis of all metrics are monetized in order to be associated to shareholder value.  For projects conducted by the company, earned value (EV) is the metric that is used to demonstrate the value that the project bears to date, as well as the projection for costs based upon the performance to date.

Back in the day when all projects were managed employing a Gantt waterfall methodology, the project manager could easily set up a structured EV model using available tools, such as Microsoft Project, adhoc tools based upon customized spreadsheets, or a combination thereof.  Assuming all of the labor and other direct and material costs were included in the working schedule, then the time phased plan could be baselined, and the tracked actuals and any such execution changes could be updated thereby providing an accurate model of the project roll out.  This approach is still used in some industries, but what I have found is that this linear model system simply cannot accurately plan out a time phased precast detailed activity set over the full scope and duration of the project with any realistic chance of executing within reasonable and acceptable contingency both in cost and time.  Several factors such as ambiguity, overzealous risk adversity, and market dynamics are among the instigators.

Many factors in market, enterprise management, and general stakeholder expectation have changed the playing field so profoundly that the waterfall methodology can not accurately model the detailed activities in the same way that it had classically managed with such success in past generations.  The two things that have remained constant are project fiscal budgets, and market launch date expectations which tend to be fixed at an early stage and are expected to remain constant.

Agile Project Managers must still provide EV metrics using the classical formulas as are still taught and are the foundation of EV measurement as per the Project Management Institute (PMI).  We can still successfully apply linear EV formulas; however, we need to recognize, manage, and account for the dynamic work roll out which is best managed by employing an Agile framework.  What this means is that the EV calculation must adapt a Piece Wise Linear (PWL) model to wrap around the Agile framework.  The EV claim updates (i.e. the Physical % Complete) must be based on objective tangible work/cost performed; therefore, a defined relationship must be set between the task(s) that collect EV claims and the team execution.  Assuming the team is executing under an Agile framework, a translation can be established that will achieve accurate EV claims.  The team does not have to change the way they execute provided they are following a developed workflow and are tracking the assignment and progress of tasks.  There must also be a developed project road map, and a corporate New Product Introduction (NPI) framework setting clear stages and gate expectations upon which the PWL is modeled.   More on these latter two topics will be discussed in future posts.

Agile Project Management – The Product is King

The local Project Management Institute (PMI) chapter, to which I am a member, conducts a Peer-to-Peer Project Management Connect group (P2P PM Connect).  I serve as a co-Champion for PM Connect.  You can find this group on We hold monthly seminars covering a wide range of PM topics.  This month’s seminar topic was “How Product and Project Managers Work Together”.  You can check out the group on Meetup at this link  For this session, we had a joint meeting with the Product Management P2P organized as a slide deck presentation followed by a panel discussion.

One of the questions posed to the panel was “How does the execution model influence the relationship and delineation of responsibilities (i.e. Agile, Waterfall, Scrum-a-fall)?”.  One view presented to this question was that Agile framework, as an execution model, had a negative influence on the relationship because it complicated the roles and responsibilities. There wasn’t a great deal of talk on this particular issue, but my interpretation was that the Product Management panelist, who presented this view, and the ensuing audience comments suggested that Agile’s microcosmic nature provided non-sensible context which led the observers to draw conflicting conclusions.  If this conclusion was reached as a result of their own personal experience, then I can only surmise that their respective company’s Agile execution model is unstructured and open ended.  By this I mean that their work environment is a series of disconnected sprints that focus on the flavor of the moment; hence may or may not work to serve the product goals.

As a panelist for Project Management, I advocated Agile framework as a beneficial execution model. My thinking is that as a Project Manager, we need to motivate the team to visualize the product as King.  In order to empower the team to serve the King, all contributions must align with the product goal.  The product goal, as primarily set by the product owner (i.e. the Product Manager) is the deliverable that composites all discrete work product deliverables.  A well organized Agile model will have a defined traceability to the product goal by way of a documented hierarchy of Epics, Story’s, and Tasks.  Dependencies can not be explicitly visualized, but the daily work must always be traceable to the product goal.

If Agile framework is, in fact, complicating the influence and delineation of Product and Project Management decisions, then I would argue that the agile visualization is exactly what that company needs.  A good visualization shows you what you have done, what you are doing now, and where you are headed.  If Project and Product manager’s don’t like the view, then they need to fix what they see; not blame glasses.