• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agile project management is systems management
 

Agile project management is systems management

on

  • 5,398 views

 

Statistics

Views

Total Views
5,398
Views on SlideShare
3,208
Embed Views
2,190

Actions

Likes
3
Downloads
61
Comments
0

20 Embeds 2,190

http://herdingcats.typepad.com 1992
http://feedly.com 138
http://www.feedspot.com 11
http://www.typepad.com 10
http://www.newsblur.com 9
http://feeds.feedburner.com 8
http://digg.com 5
http://www.inoreader.com 2
http://www.google.co.uk 2
http://newsblur.com 2
http://feedproxy.google.com 2
https://www.linkedin.com 1
http://webcache.googleusercontent.com 1
http://feedreader.com 1
http://feeds2.feedburner.com 1
http://www.aninki.net 1
http://miclark 1
http://inoreader.com 1
http://beta.inoreader.com 1
http://www.google.ae 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Agile project management is systems management Agile project management is systems management Presentation Transcript

    • Is Agile Project ManagementSystems Engineering? Systems Engineering ensures the whole product works together with its external systems to meet the needs of the customer
    • Agile Project Management can be directlyderived from Systems Engineering concepts With a SE approach, agile Robust Design and Development PM now has a solid Process and Methodology foundation in theory and in practice. ―Anecdotes,‖ can be Accelerated System Integration and Testing replaced by academic foundation Agile Systems Agile Product Development Engineering and Strategies and Architecting Approaches Agile Development Drivers Technology – Market - Regulations
    • “Whole” and “external” are core componentsof systems engineering. They also connect us toagile project management. Whole: meaning all  External: meaning aspects of product all the participants delivery  Internal customers  Technical  External customers  Business  Partners  Operations  Deployment  VARs  Maintenance  ISVs  Withdrawal  Funders
    • The idea of “agile” systems and managementgoes back long before the current paradigmchange in Agile Project Management Evolution is a technique for producing the appearance of stability. A complex system will be most successful if it is implemented in small steps and if each step has a clear measure of successful achievement as well as a ―retreat‖ possibility to a previous successful step upon failure. You have the opportunity of receiving some feedback from the real world before throwing in all resources intended for a system, and you can correct possible design errors... Tom Gilb, 1976
    • Traditional approaches to management startwith “plans.” These plans are characterized byboth their behaviors and their artifacts Work is planned in stages Single pass or sequential development of detail Doucment driven communication processes Open loop (sequential) feedback
    • We’ve known for a long time of the “dangers”associated with sequential, open loop systems,even though we easily fall into the trap is usingthem in our current work processes …there are dangers, too, particularly in the conduct of these [waterfall] stages in sequence, and not in iteration, i.e., that development is done in an open loop, rather than a closed loop with user feedback between iterations. The danger in the sequence [waterfall approach] is that the project moves from being grand to being grandiose, and exceeds our human intellectual capabilities for management and control. — Mills, 1976.
    • Systems Engineering impacts onthe sequential processes of thepast Systems engineering takes a different approach to work processes. One based on the integrated ―whole,‖ defining both the product and the process in a continuously evolving improvement paradigm
    • Systems Engineering touches a variety of topicsin a software development project. Notcontrolling these processes, but integratingthere products and processes Systems engineering enables subsystems to Soft Systems interact through a protocol Engineering Human Systems Software Engineering Management of interfaces Enterprise Verification The rhythm of the project Management Project Systems And Validation is built around the flow of Management Engineering Hardware value through systems Engineering engineering
    • Why do we need project management at all inan agile project environment? Customers demand insight into the use of their funding from a ―risk management‖ point of view Measures of progress go beyond the linear production of code from a customer list of ―stories‖ Coordination extends beyond the boundaries of a small group of developers into groups of strangers.
    • Where does the solution to these needs start?Create normative rules of compliance orheuristics to address needs? Using Rechtin s four classifications  Normative  Rational  Participative  Heuristic The normative approach results in ―guidebooks‖ of how to manage a projects Rational approaches (Systems Engineering) provide the basis of Participative and Heuristics methods
    • What is Project Management?What is Agile Project Management?Why are they different from each other?What does this mean to the profession? The normative answer is not very satisfying for agile participants Fernando Flores, PhD Thesis Communication and Management in the Office of the Future, University of California Berkeley, 1982, says it better in our agile vocabulary: Management is that process of openness, listening, and eliciting commitments, which includes a concern for the articulation and activation of the network of commitments, primarily produced through promises and requests, allowing for the autonomy of the productive units. Apply the Flores definition to projects and we’ve got an agile view of Project Management through the eyes of a Systems Engineer  Remember the ―whole‖ and ―external‖ attributes of systems
    • The confusion between traditional and agilestarts with the false assumption that“traditional” project management is notconcerned about value production The premise that ―traditional‖ project management is not focused on the same things ―agile‖ project management is misguided at best and poorly informed at worse ―Traditional‖ project managements places these concerns in the ―business management‖ domain, not the project management domain ―Traditional‖ project management is focused
    • Adding business management to projectmanagement “may” be the basis of agile projectmanagement, but some more thought is neededto understand the consequences Systems engineering (systems management) has similar concerns  Product and process performed in parallel  Value focused decision making – trades Systems Engineering has a firm foundation of process and theory  Project management is but one part of Systems Engineering
    • Why do we care about this definition?How does this definition influence how we talkabout project management? If Project Management is just about the processes then we’re missing the solution to most of the problems  Flore’s ―management‖ definition  It’s the People! The PMI definition is necessary, but not sufficient for success  A human centered process are missing Defining ―what does done look like‖ is the starting point
    • Long before the current paradigm discoveryIterative Development was the basis of goodsystems engineering practices The basic approach [Randell‘s and Zurcher‘s Iterative Development] recognizes the futility of separating design, evaluation, and documentation processes in software-system design. The design process is structured by an expanding model seeded by a formal definition of the system, which provides a first, executable, functional model. It is tested and further expanded through a sequence of models, that develop an increasing amount of function and an increasing amount of detail as to how that function is to be executed. Ultimately, the model becomes the system. — Lehmann, 1969
    • Common themes that Agile ProjectManagement professes are claimed to not bepresent in other approaches Significantly less documentation is needed to define the needs of the project Small development cycles Emphasis on team work and collaboration Adaptive development processes What is recognized is – these are the principles of Systems Engineering as well
    • What is a System and what is the discipline ofSystems Engineering?How is this important to Agile ProjectManagement? System – is an interacting combination of elements, viewed in relation to function  Machine elements (algorithms, processes, rules)  Environmental elements (external influences)  Human elements (interactive behaviors)  Emergent behaviors (alterations to behavior) Systems Engineering – is the art and science of creating complex systems
    • Complex systems are the target space ofSystems Engineering. Integrating the productand the process is the basis of complex adaptivesystems. Both interact to form a “system” The systems approach is fundamentally different from ―traditional‖ project management But, systems engineering still uses core project management processes It combines product and process in a single discipline.
    • What Are The Elements OfProject Management? There are several descriptions of ―project management.‖ The current agile approaches do not include the normative components, this is likely a gap that needs to be filled before they can be applied outside agile software development
    • If project management as a profession is welldeveloped, why don’t we recognize theelements of project management in agile projectmanagement? Project Management Institute elements Software Engineering Institute CMMI IPPD Project Management Prince2
    • What are the elements of asystems management process? No matter what the software development methodology, a set of systems management processes can be found in some form
    • Systems management processes are the basis ofagile project management Management – code development needs Organization – staffing and business processes Engineering – building the system requires more than just stories and coding processes
    • Management processes involved in the projectmanagement activities. These activities involveboth people and processes. Scaling theseprocess outside the small group is an issue Subcontract management Inter-Group Coordination Risk management Tracking and Oversight Quality management Configuration Management Planning Data management
    • There are organizational processes involved inproject management as well Competency development Technology management Process management and improvement Environment and Tool support
    • Systems engineering processes can now beconnected to the project management processes System concept definition  Making this connection Requirements and breaks the normative functional analysis paradigm System design  Replacing it with a participative and heuristic Integrated engineering paradigm of agile project analysis management System integration System verification System validation
    • A systems engineering viewof requirements Design ideas can not be judged or validated except with respect to the functional, quality, and cost requirements they must satisfy – Tom Gilb
    • Requirements are part of the process not matterthe project management method is used – agileor not How can any software process be successful if it does not attack the requirements? Agile methods use testing to provide validation Requirements are identified through prototyping Agile processes do not explicitly address of verification
    • What is requirements management all about?The process of managing change to therequirements for a system The principal concerns of requirements management  Managing changes to agreed requirements  Managing the relationships between requirements  Managing the dependencies between requirements Managing requirements without traceability?  A requirement is traceable is the requestor is known, the reason the requirement exists is known, how the requirement relates to other requirements and how it related to the architecture, implementation and user documentation.
    • Stable requirements and volatile requirements –they’re the same and they’re different It is common in all projects the requirements chances occur while they are being elicited Stable requirements concern the ―essence‖ of the system and its application domain Volatile requirements are specific to the instance of the system in a particular environment or product configuration.
    • Factors influencing requirements changes canbe addressed by project management processes Requirements errors, conflicts, omissions, inconsistencies Evolving customer, market, and user- knowledge needs Technical, schedule or cost changes Changing market or customer priorities Organizational changes
    • Volatile requirements is too broad a term to beuseful in practice. Here are four simple classesof requirements volatility found in systemsengineering Mutable – environmental changes Emergent – as the system develops Consequential – new assumptions of use Compatibility – equipment or process
    • Traceability from requirements to deliverableelements of the project forms the basis of“testing” compliance with customer needs Information used to assess the impact of requirements changes Types of traceability  Backward from – links requirements to their source  Forward from – links requirements to design  Backward to – links design and implementation to requirements  Forward To – links documents to relevant requirements
    • Verification and Validation are part of theproject management domain as well asdevelopment Verification – ―are we building the product right?‖ Validation – ―are we building the right product? Test – validation – is different from inspection – verification.
    • The tyranny of requirements is independent ofthe project management methodology ―If someone is trying to contract for a system, and they can properly identify all the necessary ‗requirements‘, then it makes sense to do so. The preference then usually becomes: ―meet the requirements, and pick the lowest cost.‖ But the reality is, in every complex system Ive seen, ―most ‗requirements‘ arent.‖ Given the right combination, nearly any ‗requirement‘ will be relaxed to obtain some other gain. The real preferences are hidden behind the ‗requirements‘ in some operational analysis space. … As soon as someone lists a set of ‗requirements‘ without indicating what makes one system better than another, theyve lost the information for comparison.‖ – Eric Honour, President INCOSE
    • The inevitable pain of software developmentcomes from the efforts to manage requirementsin the presence of change Every major aspect of software development includes at least one step that is so painful that programmers habitually avoid it. The biggest problem is remembering all the requirements. You get more requirements while working on initial requirements. you forget to write them down in the excitement of coding, and feel guilt if you spend too much time on requirements, instead of coding. Changing requirements cause the most pain of all. – Dan Berry, University of Waterloo, Waterloo Ontario
    • Why do we need to augment agile softwaredevelopment with Project Management?Where’s the value to agile softwaredevelopment? Multiple phases of product development exist in any sufficiently complex environment  Exploration – research, concept synthesis, product and market analysis  Development – technical management, development lifecycle processes  Operations – field operations, minor updates, anomaly resolutions
    • Systems engineering processes address the gapsbetween agile development methods and theirbusiness management Systems engineering considers the Full lifecycle of product development  Exploration  Customer needs  Technologies  Concept of operations  Development  Technical management  Operations  Field operations  Maintenance, update and support
    • How can we recognize the right process whenwe see it? Are there work products that go unused?  Documents  Analyses that don’t turn into features Is product quality at the target level?  Rework  Field problems Is project performance at the target level?  Cost and schedule performance  Value connected to investment
    • Project management is really a technicalbusiness management discipline. Agile softwaredevelopment is product development. They arenot competitors What is project management?  PMI processes: Initiating, Planning, Executing, Controlling, Closing  CMMI IPPD PM processes: Planning, Monitoring and Control, Supplier Management, Integrated Product Management, Risk Management, Integrated Teaming The agile paradigm must address each of these traditional process areas  If it doesn’t then is agile project management, project management – or something else?
    • Primary role of Agile “project management” isfocused on the same things as “traditional” PM– the delivery of value to the customer. Verify that the ―right‖ plan is being followed Traditional Project Management takes action in the presence of deviations  Process areas do not question of the plan is the right plan Agile Project Management focuses on the flow of ideas rather than task completion  Know the Significant Accomplishments  What does ―done‖ look like?  Are we building the right thing?
    • Technical aspects of Systems Engineering andAgile Project Management Architecture – existing and new capabilities Analysis – capacity usage, response time, allowed usage Operational concepts – new requirements Balancing disciplines – overview of all the aspects of the system
    • The core of any agile project managementprocess – experimentation Experimentation matters because it is through learning equally what works and what doesn‘t that people develop great new products, services and entire businesses. But in spite of lip service that is aid to ―testing‖ and ―learning from failure,‖ today‘s organizations, processes, and management of innovation often impede experimentation.‖
    • Three stages of project control systems.Assessing the stage is critical to assessing theproject’s success Stage 1: Stage 2: Stage 3: Chaos Prescriptive Control Adaptive Control Minimum  Conformance to  Conformance to controls plan acceptable results ―Just do it‖  ―Plan the work, work  ―Embrace Undefined the plan‖ change‖ lifecycle  Task based  Iterative, (horizontal planning) incremental and feature Driven
    • Tom Glib’s Evolutionary Systems EngineeringApproach is a nice bridge between Agile ProjectManagement and Systems Engineering Decompose the problem by  Design to cost performance results and  Design to performance stakeholders Do the high risk steps first  Invest in open ended and learn how the unknowns architectures early really perform  Motivate the team through Focus on improving the most results rewards valuable performance  Prioritize changes by value objectives first not by their place in the Base early evolution on queue existing frameworks and stakeholders  Learn fast, change fast, adapt to reality fast
    • Bibliography B. Randell and F.W. Zurcher, ―Iterative Multi-Level Modeling: A Methodology for Computer System Design,‖ Proceedings of IFIP, IEEE CS Press, 1968, pp. 867-871. C. Larman and V. R. Basili, ―Iterative and Incremental Development: A Brief History,‖ IEEE Computer, June 2003, pp. 47-56.