1 Agile Project Management Jan Pool NioCAD University of Stellenbosch 16 April 2008
2 Introduction Objective: Introduce a general Agile Project Management framework. Target Audience: Product, program and project managers. R&D executives. Product development teams. Disclaimer: APM is not the best suited approach for all projects. Remember No Silver Bullets Frederick P. Brooks.
3 Sources Primary source: Agile Project Management Creating Innovative Products: Jim Highsmith ISBN-10: Cost about $40 at Amazon. Secondary sources: Project Management Body Of Knowledge, 3 rd Ed. (PMBOK): Project Management Institute ISBN-10: X Cost about $30 at Amazon. Personal experience.
4 Product Development Environment Lots of new products on the market. Software, consumer electronics, vehicles, clothing, furniture, pharmaceuticals, consumer food products, etc. New products appear frequently. Organisations need to constantly innovate to stay competitive. New or improved product offerings. Markets may change quickly. Organisations must keep pace with change. Cost of product development is decreasing. People s attitude towards work is changing. A landscape of opportunity, uncertainty and risk.
5 Product Development Environment Linear thinking, prescriptive processes and enforced practices struggle in the new environment. The classic Plan-Do PM methodology cannot keep pace and needs to be adapted. Evolutionary lesson If the environment change, your strategy must change as well. A mindset change is required.
6 Exploratory Process An exploratory process is more suitable. Focus change from anticipation (define, design, build) to adaptation (envision, explore, adapt). Keys to reliable innovation: Continuous innovation. Current requirements. Product adaptability. Future requirements. Reduced delivery schedule. Market window and better ROI. People and process adaptability. Product and business change. Reliable results. Growth and profitability. Agile Project Management is one such methodology.
7 Agile Principles Agile Manifesto Individuals and interactions over processes and tools. Working [products] over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. While there is value in the items on the right, we value the items in the left more. Adapted from by J. Highsmith. Software replaced with products.
9 APM Framework People are more important than processes, but processes are still important. Processes do not need to be static and prescriptive. Process improvement does not have to mean rigid standardisation and certification. Process must be coupled with business objectives. Repeated manufacturing -> Prescriptive. Reliable innovation -> Flexible. Follow agile values and principles and derived practices.
10 APM Framework Qualities Support an envision, explore adapt culture. Support self-organising, self-disciplined teams. Promote reliability and consistency to the extent possible given the level of project uncertainty. Be flexible and easy to adapt. Support visibility into the process. Incorporate learning. Incorporate practices and support each phase. Provide management checkpoints for review. Verbatim from APM pg. 80.
11 APM Framework - Phases Phase: Envision Product vision and scope. Project community and team collaboration. Phase: Speculate Feature analysis. Feature based iteration, milestone and release plans. Phase: Explore Deliver features in short time-boxed iterations. Phase: Adapt Review results, team performance and current needs. Adaptive action. Phase: Close Conclude project and share knowledge outside project team. Celebrate. Compare with this with classic PM model: Initiate, Plan, Manage, Control.
12 APM Framework Phase Diagram Envision Speculate Explore Adapt Close
13 Envision Phase Objectives: Defining product vision and objectives. Vision bounds exploration. Scope and constraints. Participants. Development approach. Market and feasibility studies as starting point.
14 Envision Phase - Practices Product vision: Product vision box and elevator statement. Product architecture and guiding principles. Project scope: Project data sheet. Project community: Get the right people. Participant identification. Customer team-developer team interface. Approach: Process and practice tailoring.
15 Envision Phase Practice 1 Practice: Product vision box and elevator test statement. Help product team to create a concise shared vision. Whole product team should participate. Vision box: Product name. Key selling points. Detailed features. Operating requirements. Graphics. Elevator test statement: Sell product in less than two minutes. For (target customer) Who (statement of need or opportunity) The (product name) is a (product category) That (key benefit, compelling reason to buy) Unlike (primary competitive alternative) Our product (statement of primary differentiation)
16 Envision Phase Practice 2 Practice: Product architecture. Internal plumbing of the project. Platform, components, interfaces. Use Feature Breakdown Structure (FBS) to provide a high-level architectural view. Architecture and team structure should coevolve. Define a set of guiding principles.
17 Envision Phase Practice 3 Practice: Project data sheet. Single page summary of scope, schedule and resources. Client or customers. Project manager. Product manager. Project objective statement. Trade-off matrix. Exploration factor. Delay cost. Key features. Client benefit. Performance and quality attributes. Key architectural components. Issues/risks.
18 Envision Phase Practice 4 Practice: Get the right people. Appropriate technical capability. Self-discipline. Process is less important than people.
19 Envision Phase Practice 5 Practice: Participant identification. Identify all participants and their roles. Customers Provide requirements. Project team Develop product. Stakeholders Contribute constraints. Critical Critical to success. Essential Can delay project. Nonessential Interested parties. List of participants can include: Executive sponsor, project manager, product manager, lead engineer, management, customer team, project team, suppliers, government.
20 Envision Phase Practice 6 Practice: Customer team-developer team interface. Define the collaboration interface between the customer team and the developer team. Information flow and channels. Accountability and responsibility. Distinguish between product and project manager. Face-to-face interactions are more valuable than documentation.
21 Envision Phase Practice 7 Practice: Process and practice tailoring. Tailor a process and practices framework that defines the team s approach. Team must agree on an approach and follow it. Start with organisation s standard approach. What process and practices to use? What additional practices to use? Which ones should be modified? What level of formality is required? Process and practices might evolve during project.
22 Speculate Phase Objectives: Determine product features and constraints. Create release, milestone and iteration plans. Employ short time-boxed iterations. Feature based development. Product managers control features. Developers control design and implementation. Plans are speculative and will change.
24 Speculate Phase Practice 8 Practice: Product feature list. Create a feature list, starting with the vision. A feature is a piece of product that delivers some useful and valuable functionality. Evolutionary process. Organise as a hierarchy. Product, component, group, feature. Product, business subject area, business activity, feature. Prioritise features.
25 Speculate Phase Practice 9 Practice: Feature cards. Record basic feature information, high-level requirements and work estimates. Identify features, do not define. Discuss features in detail with customer teams. Items that can be on a feature card: Feature identifier and name. Feature description. Feature type. Estimated work effort. Requirements uncertainty. Feature dependencies. Acceptance tests. Use the back of cards to record technical activities.
26 Speculate Phase Practice 10 Practice: Performance requirements cards. Record the key operation and performance requirements. Items that can be on a performance card: Performance identification and name. Performance description. Difficulty in achieving. Acceptance tests.
27 Speculate Phase Practice 11 Practice: Release, milestone and iteration plan. These plans present a roadmap of how the team will implement the product vision. Base plans on Feature Breakdown Structures (FBS) instead of Work Breakdown Structures (WBS). Three levels of plans: Releases, milestones and iterations. Plans should focus on: Delivering value to customers. Reducing risks.
28 Speculate Phase Practice 11 Iteration 0: Use in larger projects to allow more time for planning. Iteration 1-N: Decided on iteration, milestone and release periods. Iterations should have themes to focus the team. Assign features to iterations. Incorporate schedule and resource constraints. Focus on highest value or risky features first. Larger projects can use component level planning.
29 Speculate Phase Practice 11 How much to plan? Complete plan. Two iteration plan: next and everything after. Iteration-by-iteration. In all cases, the next iteration should always be planned in more detail by the team. Determine first feasible deployment date. Plan and prepare for deployment. Use continuous integration early in project life.
30 Speculate Phase Practice 11 Estimation. Use standard techniques. Estimate by feature, not activity. How do you estimate the unknown? Use progressive estimation. Scope evolution. Scope change is inevitable in exploration projects. Manage scope creep. All parties must be aware of scope creep implications. Risk analysis and management should be part of plan. Adapt plans to address risks.
31 Explore Phase Objectives: Deliver high-value customer features. Utilise low-cost change technical practices. Develop an adaptive, collaborative project community. Project manger s duties: Help team to articulate and understand goals and constraints. Help team to interact effectively. Facilitate decision making process. Develop team members. Ensure appropriate feedback is gathered and incorporated. Track progress and deal with reality when things get off track.
32 Explore Phase - Practices Deliver on vision and objectives: Workload management. Technical practices: Low-cost change. Project community: Coaching and team development. Daily team integration meetings. Participatory decision making. Daily integration with the customer team.
33 Explore Phase Practice 12 Practice: Workload management. Team manages day-to-day activities. Team members should be self-disciplined and accountable. Project manager should monitor progress and provide guidance. Avoid micro-management! This requires a person with sufficient technical knowledge.
34 Explore Phase Practice 13 Practice: Low-cost change. Reduce the cost of iterative development. Keep the cost of change and experimentation at a minimum. Technical debt must be met. Minimise it. Simple design. Frequent integration. Ruthless testing. Opportunistic refactoring.
35 Explore Phase Practice 14 Practice: Coaching and team development. Unleash the team s capabilities by helping each team member to continuously improve. Get the right people. Focus on delivering results. Move from individuals to a team. Trust, respect and privacy. Interaction and equal contribution. Attach issues not persons. Develop individuals capabilities. Provide team with adequate resources. Customers also needs coaching. Manage team rhythm.
36 Explore Phase Practice 15 Practice: Daily team integration meetings. Coordinate team member activity daily. Raise issues, but do not discuss solutions. PM should address. Short meetings attended by all team members. Three questions: What did you do yesterday? What are you planning to do today? What impediments do you face? Team should determine if the daily meetings are valuable.
37 Explore Phase Practice 16 Practice: Participatory decision making. Provide a framework to frame, make and analyse decisions. Effective decision making is a hallmark of effective teams. Frame issues. Impact of decisions? Who should provide input or be involved in discussion? Who will make the decision? Decision criteria? Decision communication: to whom and how? Who will review the decision?
38 Explore Phase Practice 16 Making the decision. Collaborate - win-win outcomes. Allow discussion to diverge first to spread views, but steer towards convergence. Set deadlines for decisions. Once consensus has been reached and a decisions was made, everyone should be committed to implementing it. Review decisions. Learn not blame. Share experience in team and organisation. Self-organisation vs. decisions by leaders. Multiple scenarios and delayed decision making. Toyota s set-based concurrent engineering (SBCE).
39 Explore Phase Practice 17 Practice: Daily integration with the customer team. Ensures the development team stays in touch with customer needs. Typically interact with one person: Product Manager. Discuss requirements, risks, tradeoffs, etc. Do not wait for iteration reviews to speak to customers. Might be a difficult practice to follow strictly.
40 Adapt Phase Feedback: Progress. Technical risks. Requirements evolution. Market related risks: Still competitive? Evaluate: Functionality. Quality. Team performance. Project status.
41 Adapt Phase Questions to ask: Are customers getting value for money? Is the project progressing satisfactorily? Is the project team adapting effectively to changes imposed by management, customers or technology? Adaptive action, not corrective action.
42 Adapt Phase Practice 18 Practice: Product, Project, and Team Review and Adaptive Action. The objectives are: To reflect, learn and adapt. Allow the team to change pace for a while.
43 Adapt Phase Practice 18 Customer focus groups. Demonstrate completed functionality to customer team. Sessions: Facilitated. Small customer group. Review product, not documentation. Focus on changes, not detailed requirements. Wider customer audience, more view points. Form of acceptance test, wider than system. Record change requests. Build customer-development team relationship. Changes are reviewed by development team after session. Feedback to customers only later.
44 Adapt Phase Practice 18 Technical review. Happens continuously during iteration. Scheduled reviews: Facilitated. Small group of competent developers. Review product, selected documentation and statistics. Look at technical issues, design and architecture.
45 Adapt Phase Practice 18 Team performance evaluation. Questions: What went well? What didn t go so well? How do we improve the next iteration? What don t we understand? Team self-assessment. Performance. Behaviour. Evaluate processes and practices.
46 Adapt Phase Practice 18 Scope and value status. Measure features completed per iteration. What is the financial value of the features delivered? Schedule status. Determine the expected time to project completion. Determine shortest, probable and latest completion dates. Constant variance over time means risks and uncertainty is not sufficiently managed.
47 Adapt Phase Practice 18 Cost and resource status. Use organisation s accounting system if not too heavyweight. Determine the expected cost to complete project. Quality status. Use existing quality measures. Proportion of code tested. What is the team s assessment?
48 Adapt Phase Practice 18 Project team information. Share key project information with the team. Visual. Prominent. Concentrate on vision, scope and issues/risks. Adaptive action. Minor tweaks. Update iteration and delivery plans. Technical, resource and schedule adjustments. Management focus: Delivering value. Reduce risks.
49 Close Practice 19 Practice: Close Celebration! Show appreciation to the team. Closure: Indicates project completion. Cleanup open items. Organisational knowledge transfer. Project retrospective.
50 Final Comments APM is a good approach for exploration projects, such as new product development. APM can be applied to general product development, not just software. Be pragmatic, adapt processes and practices to project and organisation s needs. Try APM on smaller projects first.
Agile Project Management Jim Highsmith Chapter 5 An Agile Project Management Model We improve effectiveness and reliability through situationally specific strategies, processes, and practices. One of the
Scrum Is Not Just for Software A real-life application of Scrum outside IT. Robbie Mac Iver 2/9/2009. Agile methods like Scrum can be applied to any project effort to deliver improved results in ever evolving
Integrating Scrum with the Process Framework at Yahoo! Europe Karl Scotland Yahoo! Europe email@example.com Alexandre Boutin Yahoo! International firstname.lastname@example.org Abstract Large enterprise
AGILE FOUNDATION CERTIFICATE SAMPLE FOUNDATION QUESTIONS WITH ANSWERS This document is a set of sample questions, in the style of the Agile Foundation Certificate Examination, which is a 60 question, 1
Agile-Waterfall Hybrid Jessica LaGoy, MS, PMP About Jess BS Applied Physics, WPI / MS Cybersecurity, UMUC PMP, ITIL, Data Scientist, Tableau, Alteryx Project Experience Data and technology Construction
Agile Project Management By Mark C. Layton Agile project management focuses on continuous improvement, scope flexibility, team input, and delivering essential quality products. Agile project management
The Basics of Scrum An introduction to the framework Introduction Scrum, the most widely practiced Agile process, has been successfully used in software development for the last 20 years. While Scrum has
Agile Project Management Jim Highsmith Chapter 1 The Agile Revolution Ultimate customer value is delivered at the point-of-sale, not the point-of-plan The key opportunity, uncertainty, and risk resides
Introductory Certificate The APM Project Fundamentals Qualification. Examination paper Candidate Number Date Location Examination Paper Sample Paper v1.4 General Notes Time allowed 1 hour. Answer all 60
Agile Software Development 7 Steps to Successful Projects 2012 Kynetix Technology Group INTRODUCTION Many organisations adopt an Agile approach to software development and later wonder why applications
Agile and PRINCE2 And how they integrate enterprise.bcs.org 02 Agile and PRINCE2 And how they integrate Introduction Within the world of method frameworks it is very easy to become polarised on one specific
Scaling Scrum Colin Bird & Rachel Davies Scrum Gathering London 2007 Scrum on a Slide Does Scrum Scale? Ok, so Scrum is great for a small team but what happens when you have to work on a big project? Large
D25-2 Agile and Scrum Introduction How to Use this Download This download is an overview of a discussion Intertech has with clients on Agile/Scrum This download has an overview of Agile, an overview of
HOW STRATEGIC ROADMAPPING ADDS VALUE Irene J. Petrick, Ph.D. June 2010 In the past several years, I have actually heard several mid- to senior-level executives challenge their teams to drive for disruptive
Introduction to Agile Scrum by Julia M. Lobur Penn State Harrisburg CMPSC 487W Fall 2015 Introduction to Scrum Learning Goals Relationship of Scrum to other Agile methods Scrum Framework Scrum Roles Scrum
Rally Software Development Corporation Whitepaper Mastering the Iteration: An Agile White Paper Dean Leffingwell Abstract: The heartbeat of Agile development is the iteration the ability of the team to
Delivering Successful Projects, Tom Moriarty, MDR Consulting This paper outlines the critical requirements of success in managing projects of all types from the definition of a business need to the delivery
1 www.stephenbarkar.se Lean vs. Agile similarities and differences 2014-08-29 Purpose with the material 2 This material describes the basics of Agile and Lean and the similarities and differences between
04_Highsmith.qxd 3/1/04 5:47 PM Page 77 Chapter 4 An Agile Project Management Model Principles and Practices Hi, Maya, it s Herman. Hi, dude, how s your project going? asked Maya. Pretty well. Things are
Becoming Agile: a getting started guide for Agile project management in Marketing, Customer Service, HR and other business teams. Agile for Business www.agilefluent.com Summary The success of Agile project
Agile Software Development Use case for Agile Software Development Methodology in an Oil and Gas Exploration environment. White Paper Introduction No matter what business you are in, there are critical
About the Tutorial Agile is a software development methodology to build a software incrementally using short iterations of 1 to 4 weeks so that the development is aligned with the changing business needs.
WHY DO I NEED A PROGRAM MANAGEMENT OFFICE (AND HOW DO I GET ONE)? Due to the often complex and risky nature of projects, many organizations experience pressure for consistency in strategy, communication,
6. Software Lifecycle Models A software lifecycle model is a standardised format for planning organising, and running a new development project. Hundreds of different kinds of models are known and used.
What Does a Business Analyst Do on an Agile Project? By Kent J. McDonald Senior Instructor, B2T Training As the use of agile approaches increases, business analysts struggle to determine how their role
Scrum Guidelines v.2 2011 W W W. S C R U M D E S K. C O M WHY Agile Ceremonies Agile project is developed in repeatable ceremonies that give rhythm to delivery. Product Strategy Once per year Release Planning
Process Methodology for Wegmans Deli Kiosk Version 1.0 Prepared by DELI-cious Developers Rochester Institute of Technology September 15, 2013 1 Table of Contents 1. Process... 3 1.1 Choice... 3 1.2 Description...
Agile Quick Facts AGILE PRINCIPLES Customer Satisfaction 01 Changing Requirements 02 Frequent Delivery 03 Collaboration 04 Our highest priority is to satisfy the customer through early and continuous delivery
Project Management: PMBOK and more MIEIC, Laboratório de Gestão de Projectos Ademar Aguiar FEUP, Universidade do Porto http://www.fe.up.pt/~aaguiar/ email@example.com FEUP Ademar Aguiar MIEIC/LGPR,
Agile Systems Engineering: What is it and What Have We Learned? March 2012 Dr. Suzette S. Johnson Agile Engineering Northrop Grumman Suzette.Johnson@ngc.com Getting To Know You! Dr. Suzette Johnson Northrop
Rolling Wave Planning: Manage Projects Without Going Under Rolling Wave Planning: Manage Projects Without Going Under W. Charles Slaven MBA PMP CSSBB CPA (inactive) Director, Lean Deployment and Continuous
Locassa App Essentials Agile Explained What you'll learn 1. Agile Overview The main principles for better software 2. In Essence The basics of a proven method 3. Want to know more? Whether at idea stage
SATORI CONSULTING LEAN AGILE POCKET GUIDE Software Product Development Methodology Reference Guide PURPOSE This pocket guide serves as a reference to a family of lean agile software development methodologies
Agile Software Development in the Large Jutta Eckstein 1 Large Large in... Scope Time People Money Risks We concentrate on Large Teams Large is relative 1, 2, 10, 100, 2000 People 2 Principles behind Agile
Jukka Mannila KEY PERFORFORMANCE INDICATORS IN AGILE SOFTWARE DEVELOPMENT Information Technology 2013 KEY PERFORFORMANCE INDICATORS IN AGILE SOFTWARE DEVELOPMENT Mannila, Jukka Satakunnan ammattikorkeakoulu,
Business Intelligence Project Management 101 Managing BI Projects within the PMI Process Groups Too many times, Business Intelligence (BI) and Data Warehousing project managers are ill-equipped to handle
Agile Software Development in the Large GI-Vortrag Braunschweig Jutta Eckstein Nicolai Josuttis What Does Large Mean? Large in... scope time people money risks We focus on Large Teams which implies everything
Laboratório de Desenvolvimento de Software FEUP/MIEIC, 2015/16 Ademar Aguiar Nuno Flores Rui Maranhão Hugo Ferreira Luís Teixeira url: moodle http://www.facebook.com/notes/facebook-engineering/visualizing-friendships/469716398919
Lean and Agile Development With Scrum (Part 1) Lucio Davide Spano firstname.lastname@example.org email@example.com 3 May 2012 Agile Programming http://www.dilbert.com Traditional Software Development Waterfall
MODULE 10 CHANGE MANAGEMENT AND COMMUNICATION PART OF A MODULAR TRAINING RESOURCE Commonwealth of Australia 2015. With the exception of the Commonwealth Coat of Arms and where otherwise noted all material
THE UNITED REPUBLIC OF TANZANIA PRESIDENT S OFFICE PUBLIC SERVICE MANAGEMENT ICT Project Management A Step-by-step Guidebook for Managing ICT Projects and Risks Version 1.0 Date Release 04 Jan 2010 Contact
Foreword Introduction Part One The Evolving State of ESPM xxxi xxxiii 1 Chapter 1 The Changing Landscape of Software Development What Is a Software Development Project? Examples of Two Software Development
IMQS TECHNOLOGY AGILE METHODOLOGY OVERVIEW Agile software development refers to a group of software development methodologies that promotes development iterations, open collaboration, and process adaptability
A Viable Systems Engineering Approach Presented by: Dick Carlson (firstname.lastname@example.org) Philip Matuzic (email@example.com) i i Introduction This presentation ti addresses systems engineering
Agile Beyond The Team 1 Dilbert Agile 2 What Does Your Organization Value? Projects over Teams? Do new teams spools up for new projects? On-Time/On-Budget Delivery over Zero Maintenance Products Deliver
PMI Virtual Library 2010 Carole Wittemann Business Intelligence Project Management 101: Managing BI Projects Within the PMI Process Group By Carole Wittemann, PMP Abstract Too many times, business intelligence
Jan Marek Jan.Marek@ca. com CA Technologies Session S601 Introducing Agile development methodologies to mainframe development teams Agenda Introduce Agile software development methodologies Scrum overview
Role profile Basic information Job title Department Location Reports to (Job Title) Matrix manager if applicable (Job Title) Direct reports (Number or Not applicable) Overall people management responsibility
The Agile Manifesto is based on 12 principles: Customer satisfaction by rapid delivery of a useful product solution Welcome changing requirements, even late in development Working products are delivered
Organisational Change Management The only thing that is constant is change in your business, your market, your competitors, and your technology. Remaining competitive and responsive to your customers and
SEMS - Software Engineering M anagement System for Small and Medium Software Product Businesses Goals, Means & Experiences 20.1.2004 Jarno Vähäniitty firstname.lastname@example.org http://www.soberit.hut.fi/
Agile for Project and Programme Managers Author Melanie Franklin Director Agile Change Management Limited Introduction I am involved in a mixture of assignments for different organisations across Europe
Agile Service Transition PATRICK BOLGER HORNBILL SERVICE MANAGEMENT MATT HOEY GRANT THORNTON UK LLP March 2014 The need for speed Technology, and how we use it, constantly evolves. In recent years, Cloud,
This page was left intentionally blank. Workforce Planning Model Steps What This Step Accomplishes 1. Define the Scope Determines our focus could be long or short term could be a specific business unit
APM Revised Procurement Guide Chapter 2 :Concept & Feasibility 1 Draft7_Chapter2.0_Concept&Feasibility_Jan12 2.0 STAGE 0 : CONCEPT AND FEASIBILITY Having identified a potential need or opportunity, there
What is Agile: Agile is a way of developing software and other soft products focused on flexibility and adapting to changing user or customer requirements to maximise value. In many circumstances the end
Changing Roles and Responsibilities from Traditional project management to Agile project management Vishvadeep Tripathi School of computer science and IT Devi Ahilya University Indore, India email@example.com
About this research note: Technology Insight notes describe emerging technologies, tools, or processes as well as analyze the tactical and strategic impact they will have on the enterprise. Project Management:
AGILE - QUICK GUIDE http://www.tutorialspoint.com/agile/agile_quick_guide.htm Copyright tutorialspoint.com AGILE - PRIMER Agile is a software development methodology to build a software incrementally using
Human Resources Values for Working Together and Professional Behaviours A message from the Vice-Chancellor The new Human Resources Strategy, Working Together: A Strategy for Success, in tandem with the
APM-10 Agile project management Content analogy elements of traditional project management elements of agile project management conclusions Karol Frühauf, INFOGEM AG CH-5401 Baden Karol.Fruehauf@infogem.ch
Project Management and Scrum A Side by Side Comparison by Anne Loeser, October 2006 For decades, software development projects have followed the classic waterfall method in which software development initiatives
CS/SWE 321 Sections -001 & -003 Software Project Management Copyright 2014 Hassan Gomaa All rights reserved. No part of this document may be reproduced in any form or by any means, without the prior written
PMP vs. Scrum Master Compatible or Incompatible? Presented by: Karen Little, PMP, CSM, CBAP, ITIL, MCP, MBA Copyright 2007 by Karen Little 1 Agenda Introductions Background on Agile and SCRUM Methodologies
Change Manager Master Level Competency Model The Change Manager Master competency model sets an independent industry benchmark for SENIOR level change management practitioners. The model was launched in
C O N S U L T C O N N E C T - C H A N G E Does CRM Really Work? TABLE OF CONTENTS DOES CRM REALLY WORK?... 3 WHY THE RESISTANCE TO CRM?... 3 HOW DO YOU SELL CRM?... 4 CRM IS NOT JUST ABOUT TECHNOLOGY...
CSE 435 Software Engineering Sept 16, 2015 2.1 The Meaning of Process A process: a series of steps involving activities, constraints, and resources that produce an intended output of some kind A process
Job Description Senior Accountant Name Reports to Start date Permanent staff Business Services Manager TBA YES A Senior Accountant is a highly productive and functioning member of the team, managing work
DSDM Case Study An Agile Approach to Software Systems Development for the Highways Agency Government agencies are constantly striving to develop software systems that support business objectives, deliver
Agile Fundamentals, ROI and Engineering Best Practices Rich Mironov Principal, Mironov Consulting 1 About Rich Mironov Agile product management thought leader Business models, pricing, roadmaps Agile transformations
Transitioning from Waterfall to Agile Course AG01; 3 Days, Instructor-led Course Description Identify the challenges you will face when implementing an Agile approach to software development and then plan
Agile Project Management Page 1 Titel des Vortrages XX. YY. 2004 Seite 1 Page 2 Titel des Vortrages XX. YY. 2004 Seite 2 SILVER BULLET Page 3 Titel des Vortrages XX. YY. 2004 Seite 3 x * p / 2 The Uncertainty