Dennis stevens response

YET ANOTHER AGILEPRESENTATION WITH REDHERRINGSHow to confuse BAD Management with BAD process

The Red Herring An expression referring to the rhetorical or literary tactic of diverting attention away from an item of significance. The diversion is examples Agilest use for moving the Agile are simply BAD Project Management If many of the processes in GOOD project management were applied properly, there would be discussion about making improvements, rather than replacing processes.  “Waterfall” to usually the starting point for the Red Herring discussion.

Value Driven DeliveryThe notion of “value” in agile has no units ofmeasure. Engineering Economics does. The unit ofmeasure is $’s.Monetizing all decisions and actions is calledProject Management.The lack of any process to monetize actionsdisconnects the real value to the business fromthe perceived value of agile. SHOW ME THE MONEY

Value Driven Delivery Agile TraditionalDeliver value by understanding and  Define the project up front.prioritizing what is important to the  Use robust change management tocustomer and the business, continually protect against / prevent change.refining the smallest and simplest thingthat might possible work, deliveringquality results incrementally, andobtaining feedback to improve theresult.The suggested “traditional” approach is just BAD PM.Managing projects in this manner is simply BAD Project Management.No PM guidance suggests this is the correct approach. Progressive elaborationhas been in the PM literature since the early 80’s.

Value Driven DeliveryCounter DiscussionThe Conjecture The Facts Define the project up front.  No credible PM processes says to do this.  This is another “red herring” built around BAD project management.  “waterfall” is no longer allowed in DoD.  Spiral is being replaced in DoD IT projects with progressive development in Rolling Waves. Use robust change management to  Yes, someone has to control the protect against / prevent change. scope if you’re spending other people’s money.  Spending your own money – no one cares how your do it.

Value Driven DeliveryRecommended Best Practice Start with an Integrated Master Plan to define the “value assessment points” in the project  SignificantAccomplishments for each of these assessment points,  Accomplishment Criteria for the work efforts needed to produce the planned maturity. Define “value” in terms of “Engineering Economics” to remove the hand waving and replace it with tangible measures of performance. Units of measure must be $’s

Value Driven DeliveryRecommended Best Practice Maintaining the mechanisms for the interested parties are participants is necessary, but far from sufficient to success. What does DONE look like in units meaningful to these interested parties? What are the Measures of Effectiveness (MoE)?  These are measures in business units. What are the Measures of Performance (MoP)?  These are measures in technical units.

Value Driven DeliveryRecommended Best Practice For example MoE might be :  92 out of 100 of pilots satisfactorily completing primary training per unit of time  Decrease by 15% the cost of training the 100 pilots per unit of time. An example of MoP might be:  Assure the flight test article dry weight is 29kg or less by Critical Design Review (CDR)  Measure and confirm the throughput of the transaction processor can meet or exceed the maximum demand rate of 1,200 transactions / second.

Stakeholder EngagementPhysical engaging stakeholders is highly domainsensitive.The term “appropriate” is meaningless, sincethere is no unity of measure of “appropriate”Appropriate to Who? Appropriate for whatpurpose?These engagements must be defined during theproject charting process – then we’ll know what“appropriate” means.

Stakeholder Engagement Agile TraditionalEstablish and maintain mechanisms that  Throw projects over the wall acrossensure that all current and future Analysis, Design, Development, QA,interested parties are appropriately and Production.participating throughout the lifecycle  Engage end-users at the end.of the project.  Leave significant strategic decisions to the interpretation of the development organization while the project is in the black-box of development.The suggested "traditional" approach is of course BAD PM. Dont so this in anydomain or context. This was known decades ago. Those continuing to "throwthings over the wall," need to look for new work.

Stakeholder EngagementRecommended Best Practice Using the DoD 5000.02 acquisition process, establish monthly Technical Interface Meetings (TIM), monthly Program Management Reviews (PMR), and COTR and Program System Engineering representative connections. Provide weekly Earned Value in a Digital Integrated Environment, so the customer can "see" weekly performance of the program. Establish an Integration Laboratory to verify proper (to specification) operational capabilities of each Rolling Wave deliverable.

Boost Team PerformanceAll the principles of agile are also present in anymodern, successful team.These attributes have been in place JohnKatzenbergs The Wisdom of Teams.Falling to put these ideas to work is not theproblem of traditional management, it’s theproblem of BAD Managers. The best Red Herring so far.

Boost Team Performance Agile Conjectured TraditionalBoost team performance through  Focus on resource optimization.creating an environment of trust,  Form teams around projects.learning, collaborative decision  Share resources across multiplemaking, commitment and conflict projects simultaneously.resolution, thereby enhancing  Take power away so people just dorelationships amongst individual team what they are told according to themembers. standards. Put all decision making into the hands of few key managers.The traditional and agile approach is highly sensitive to the businessenvironment. For internal IT the focus of projects may be less than in a "contract"based engagement. It is critical to establish Domain and Context. In all domains,the "team" is the source of success.

Boost Team PerformanceCounter DiscussionThe Conjecture The Facts Focus on resource optimization.  This may be necessary depending on the domain and context. Form teams around projects.  This is also domain and context dependent. Share resources across multiple  Multitasking reduces effectiveness. projects simultaneously. But the reality of project work must deal with this at times. Take power away so people just do  This is simply BAD management. what they are told according to the  Any intellectual property standards. development manager knows better. If this happens fire that manager and get a better one. Put all decision making into the  This is another “red herring.” hands of few key managers.  Fire that manager, get another one.

Boost Team PerformanceRecommended Best Practice Establish Work Package teams in a matrixed environment. Hold the Work Package team accountable for the delivery of the funded work. Enable these teams to work within their budget and schedule to produce complaint products. Flow this accountability to the lowest reasonable level of the organization (Work Package) and roll up the reporting of "progress to plan" from those accountable to the work.

Adaptive PlanningPlans are Strategies for success. Planning by itsvery nature is adaptive.To suggest that Plans are fixed is to restate thatthose who have fixed plans are BAD ProjectManagers – Again.

Adaptive Planning Agile TraditionalWork with the team and the  Plan the work and work the plan.stakeholders to produce and maintain  Stick to the Gantt Chart.an evolving plan from initiation toclose based on goals, business values,risks, constraints, and stakeholderfeedback.Without some form of a Plan you cannot know what DONE looks like. Tosuggest otherwise is not only naive, it is irresponsible when youre spendingother peoples money.The Gantt Chart has been replaced with newer forms to visualize thedependencies and sequencing of work.Small or trivial projects can get by with “lists of sticky notes,” lack of visibility tothe interdependencies are root cause of schedule slips and budget overruns.

Adaptive Planning Counter DiscussionThe Conjecture The Facts Plan the work and work  Yes, all projects have Plans. the plan.  An agile project’s plan is developed during the planning sessions for the iteration. The outcomes from that plan are posted on the wall for Stories or Features to be implemented during the iteration.  This is called a Plan Stick to the Gantt  The Gantt chart can show dependencies in ways Chart. no agile method can.  If there are no dependencies, then don’t use this chart.  If there are dependencies ask how they will be shown – it may look like a Gantt

Adaptive PlanningRecommended Best Practice Establish the Integrated Master Plan for the "program architecture."  Do this with Systems Engineering process to define the "value stream" of the increasing maturity flow. The Plan is the strategy, the Schedule is the work sequence and duration (Work Package duration) for produce the elements of the "value stream."  This IMP/IMS approach is the mandated process for DoD 5000.02 programs.

Adaptive PlanningRecommended Best Practice The "value" is defined in units meaningful to the stakeholders.  Thisvalue definition process is called “Engineering Economics.” In our domain that means confirmation that the needed capabilities are available as planned and these capabilities can be verified through MoE and MoP assessments.

Problem Detection and ResolutionThis is a core process of CMMI DEV V1.3. tosuggest Traditional project management doesn’tdeal with this is to ignore established guidance.

Problem Detection and Resolution Agile TraditionalThe team identifies problems, Management identifies problems,impediments, and risks; determines impediments, and risks; determinesstrategies for dealing with them; and strategies for dealing with them; andexecutes the strategy. executes the strategy.Current Lessons Learned professionals mandate the approach of 360˚ problemdetection and resolution and have done so for decades.

Problem Detection and ResolutionCounter DiscussionThe Conjecture The Facts Management identifies problems,  How can management identify a impediments, and risks; determines problem if they are not embedded strategies for dealing with them; in the development? and executes the strategy.  This is one of those “nonsense” statements.  The strategy for dealing with the problem may certainty involve management, that’s their role.  How can management execute the strategy if it requires engineering participation? – another nonsense statement.  Read CMMI DEV V1.2 Process Areas for how to handle this.

Problem Detection and ResolutionRecommended Best Practice All problems are detected, notified, and addressed from all facets of the project – this 360˚ process is at the heart of TQM, Lean, and 6 Sigma for decades This is the basis of all “risk management processes.” It is also the basis of:  ITIL  CobiT  CMMI DEV v1.3

Continuous ImprovementContinuous improvement process have been inplace for decades.The granularity of when to stop and assessperformance improvement opportunities is abusiness and project governance decision.Guidance for this process is found in Six Sigma,Lean, TQM and other quality processes.

Continuous Improvement Agile TraditionalImprove the quality, effectiveness, and  Perform lessons learned at the endflexibility of the product, process and of the project.team and influence the organization in  Use those to update organizationalorder to better deliver value now and processes and standards.in the future.The agile suggestion while correct provides no units of measure or actionableprocesses to cause quality, effectiveness, and flexibility to appear. Initiativeslike LM21 as examples of how to put the words into practice. The LeanAerospace initiatives of MIT established this approach long before Agilediscovered the words.

Continuous ImprovementCounter DiscussionThe Conjecture The Facts Perform lessons learned at the end  This is not the recommend guidance of the project. for any credible Lessons Learned process.  Who does this?  Stop doing stupid things on purpose Use those to update organizational  Yes the lessons learned are used to processes and standards. update process and standards – that’s one of the points of LL.

Continuous ImprovementRecommended Best Practice Formal Lessons Learned processes are in place for all agencies (DoD, DOE, DHS, FAA). These LL are guided by formal (professional) LL paradigms.

Lessons LearnedAgile has tremendous value in the development ofsoftware intensive systems. But this approach of startingwith “Red Herrings,” making unsubstantiated statements,and using simple BAD Management practices as thecounter point to Agile serves no purpose.When Agile “thought leaders” start to address to “value”of Agile in the context of the business processimprovement and abandon the anecdotal experiences,then business leaders will start to listen.This is the lesson from deploying Balanced Scorecard,Lean Manufacturing, and other quality and processimprovement processes.

Lessons Learned From the Presentation Without properly applying the traditional processes - and holding managers accountable for this proper application – the "new" processes will be seen as "paving the cow path." That is – trying to apply new methods to an environment that has yet to address the systemic problems with using the traditional methods.

Lessons Learned From the Presentation The agile methods used in developing software (Scrum, XP, DSDM Crystal, RUP) address the development of products. They do not address the issues of "managing" the development of those products from the Business Governance paradigm. One example of this is the 21 Process Areas of CMMI Dev V1.2. 5 Process Areas are applicable to the development of the actual product. The other 16 deal with the business and operational aspects of a software development projects.

http://herdingcats.typepad.com	797
http://www.typepad.com	2
http://f6mail.rediff.com	1
http://www.netvibes.com	1
http://www.google.ca	1
http://translate.googleusercontent.com	1
http://131.253.14.98	1

Dennis stevens response

by Glen Alleman

Accessibility

Upload Details

Usage Rights

7 Embeds 804

Statistics

Dennis stevens response Presentation Transcript