INTRODUCING AGILE PROJECT MANAGEMENT TO THE CORPORATE WORLD* Ratko Mutavdžić, PROJEKTURA

*some ideas how you can do it, and some that you should avoid at all cost

INTRO just a few words about me

so, if we all nod our heads... we can continue...

• Ratko Mutavdzic is founder of PROJEKTURA, consulting company that work with new and emerging technologies and introduce them to the corporate and enterprise environments. Prior to this one, he spent 15 years Microsoft, starting in a consulting practice and then leading several different sales and technology teams.

• He is the author of number of published papers on different aspects of the technology, successful blogs on new technologies and project management, and active contributor in a number of social networks exploring the use and advance of new ways to connect and share innovation and invention.

• He frequently speaks on conferences, meetings, workshops, coffee shops and generally at every place where people like to explore, challenge, investigate, think and innovate.

• Keywords: change, project, program, portfolio, innovation, startup

note: more contact info on a last slide

FEW ASSUMPTIONS just to be in the same book, if not on the same page...

so, if we all nod our heads... we can continue...

• you know what the agile methodology is all about • you know what the plan driven methodology is all about • you think that agile works way better than plan driven • you still have hard time to explain to your boss that you should move

everything to agile and drop that money sucking, morale destroying, never under control thing that people are calling „project management”

note: if most of the people nod their heads, it is safe to continue...

WELCOME TO CORPORATION there ‘s no right to free speech in the workplace

why beign too smart in not too smart „human resources is not rhere to help you, but to protect the company from you”

• standard elements and barriers to overcome: • resistance to collaboration internally and externally • waterfall culture, not only in project management • low-trust environment • unwillingness to change • rigid management hierarchy

note: for more info, read a book „Corporate Confidential: 50 secrets your company does not want you to know”

IF YOU THINK YOU ARE NOT USING AGILE... like, you heard about the thing but you think that you are not ready...

does this look’s like your current plan?

note: read more about Parkinsons Law: „work expand so as to fill the time available for its completion”

1. Requirements Analysis 2. Functional Design 3. Technical Design 4. Product Development 5. System Integration 6. Quality Testing 7. User Acceptance Testing 8. Deployment

project timeline (initial)

all good plans start this way. we are safeguarding against uncertanities and risk events

THINK AGAIN. actually you are on a good track to recognize most of your projects

the plan after the meeting with the customer

note: there are some good movies filmed on this topic

1. Requirements Analysis 2. Functional Design 3. Technical Design 4. Product Development 5. System Integration 6. Quality Testing 7. User Acceptance Testing 8. Deployment

project timeline (crushed number of times)

scope same (will increase later), same resources, less time, less money

so, this is manager you are dealing with ... maybe not the look but mindset for sure

LOOK AT THE MANIFESTO you know what I am talking about...

this is not the great way to introduce the concept to the board we are confusing CXO’s even if we can do a great job in a first place

• we are uncovering better ways of developing software by doing it and helping others do it:

• individuals and interations over processes and tools • working software over comprehensive documentation • customer collaboration over contract negotiation • responding to change over following a plan

note: www.agilemanifesto.org

USUAL SUSPECTS do we understand our true value producers?

we need to explain agile way BEFORE engagement...

• not attempting to finalize the requirements early in the project -> percieved as a lack of proper communication with the stakeholders

• promoting the incorporation of change requests through the lifecycle • less emphasis on rigid upfront planning -> percieved as a lack of control • lack of documentation -> percieved lack of traceability and accountability ->

(usually lack of understanding of benefits and functionality) • need for formal processes -> lack of control over things

note: no note

AGILE IS DESIGNED TO DEAL WITH... some really nasty laws and lemma’s

agile is here to <insert_logical_reason_here>

• software projects are not predictable: specifications will never be fully understood (Ziv’s Law)

• requirements uncertainty makes scope an inadequate starting point: the user will never know what they want until after the production (Humphrey’s Law)

• the stakeholders will change requirements, change direction, or stop the project at any time: the interactive system can never be fully specified nor it can be fully tested (Wegner’s Lemma)

note: also good ones: Parkinson’s Law, Murphy’s Law, Segal’s Law (two watch, no clue of right time thing)

WHY AGILE WORKS? there are some theories that you want to read through

humanistic, goal directed approach that utilize people’s ability to manage complexity

• Theory of Constraints and Lean Thinking • Cognitive Science: how do we make decisions • Complex Adaptive Systems: how do we handle the uncertainty • Evolutionary Psychology: how do we interact

note: your manager will be lost, but at least you know why

WHAT CORPORATION WANTS FROM AGILE you know what I am talking about

to understand the business benefits of agile regardless of investment, leadership and time needed

• to understand where is ROI • to understand how you going to be faster and more predictable • to understand how they can be more responsive to market • to understand how to enable strategic flexibility • to understand how to achieve shorter dev cycles and better quality • to understand how to improve team morale

www.agilemanifesto.org

ISSUES WITH AGILE you know what I am talking about

agile is great for software development, but... regardless of investment, leadership and time needed

• to manage large-scale programs with highly dependant, sequential components (infrastructure, facilites)

• to manage concurrent projects: status, backlog, decisions, risks (overall picture)

• to manage multi-vendor environment with no agile experience • to manage context-switching due to allocation of the groups into small teams • to introduce organizational transformation and cultural changes?

www.agilemanifesto.org

now, you ask a agile guy to give you an estimate...

AGILE PEOPLE WANT TO BE DIFFERENT they want to see things differently even if they are really not ...

agile is „numbers and charts” like any other methodology and we will dive into those later during the presentation

• example: „dont say commited, say forecasted” • reality check: today, in business, forecast EQ. commited • „plan driven” project management understands the concept of

„probability” so... • we are at appx. 4M USD 2 years from project delivery • we are at appx. 3,65M USD at the planning • we are at appx. 3,340.296 USD at the delivery

the age of agile hipsters what wf people think about agile ones: „sandal wearing anarchists”

plan driven, waterfall, used to be your best friend...

WHEN TO USE AGILE AND WHEN PLAN DRIVEN 10.000 ft view on the difference, and I am not saying this is guideline

beware: plan driven can also be „half-agile” :) for example at planning we use „Progressive Elaboration” and „Rolling Wave Planning”

source: „Balancing Agility and Discipline”, Boehm & Turner

• AGILE • low criticality • senior developers • requirements change often • small number of developers • culture that thrives on chaos

• PLAN-DRIVEN • high criticality • junior developers • requirements don’t change often • large number of developers • culture that demands order

WATERFALL vs. AGILE why waterfall people always look stupid (aka Mac vs. PC thing)?

having said that...

WATERFALL vs. AGILE I LOOOOVE those comparisons... like the following: „waterfall projects rarely deliver according to a plan”

let me tell you a secret... people at „plan-driven” methodologies also want to succeed at project delivery

• occassional „customer” involvement VS. frequent „customer” involvement • potentially large team size VS. teams of 3-9 people • resistant to change VS. change is expected • requirements docs VS. just-in-time, informal requirements • task are assigned VS. assigned task are a bottleneck • multiple phases, eventual delivery VS. working software each Sprint/Iteration • contract says what we build, deliver VS. contract is a lot closer to T&E

note: this is very seriously noted at ALM 2012 Conference in Seattle

WATERFALL vs. AGILE TRUE stories why we have issues with waterfall

but that can happen to any methodology ... /

• SERIALIZED PROCESS: longer time to market; devs isolated from customer needs

• PLANNING FAR IN ADVANCE: plans no longer march reality by the implementation time

• LACK OF VISIBILITY INTO RATE OF PROGRESS: teams don’t realize they’re behind schedule until too late; features slashed very late to compensate

• LONG TIME TO PROJECT COMPLETION: customers get acccess infrequently • PROJECTS FALL BEHIND THE SCHEDULE: project miss market window

note: this is very seriously noted at ALM 2012 Conference in Seattle

so you assemble a team to implement the agile

STILL THE SAME OLD QUESTIONS but with different approach...

„when the project will be done? how much it will cost? what will be delivered? what are the risks?”

note: there are some additional questions, but you already know them...

AGILE • Deliver working product in short cycles • Keep the evolving product highly visible • Inspect outcomes frequently • Change our product or processes as we

learn more to ensure acceptable outcomes

• Do less work that will change

APPROACH • Focus less on predictive up front

planning • Focus more on delivering value • Focus more on collaboration with

the business • Focus more on engaging the

team

MAPPING PMI KA vs. AGILE i mean, not really, but to external people, it might look like that we did exactly that...

agile is „numbers and charts” like any other methodology

note: we are still waiting for a formal adoption of agile in PMI world, regardless of ACP

• PMI KNOWLEDGE AREAS • integration • scope, time, cost • quality • people • communication • risk

• AGILE • manifesto • principles • best practices

ANOTHER VIEW... of functional mapping between PMI processes and agile involvement

plan driven hidden inside the agile :) the process groups are not phases, but rather they are integrated set of processes applied iteratively throughout the project and revised as needed

paper: „Agile Project Management and PMBoK Guide”, PMI Global Congress Proceedings, Michele Sliger, 2008

Planning Release Release Retrospective

Release Planning Iteration Iteration Retrospective

Iteration Planning Daily Work Daily Work Retrospective

PROJECT

RELEASE

ITERATION

INITIATION PLANNING EXECUTING MONTORING AND CONTROL

CLOSING

PROJECT Business case or Feasibility Study

Project kickoff and visioning meeting Release roadmap planning

Iterative and incremental delivery of working software

Regular review of deliverables, progress and process

Project retrospective

RELEASE Roadmap and release definition

Release planning meeting

Iterative and incremental delivery of working software

Regular review of deliverables, progress and process

Release retrospective

ITERATION Iteration planning meeting

Iteration planning meeting

Work features through to completion (including testing)

Task boards, burndown charts, daily standups, acceptance of completed features

Iteration demo, review and retrospective

Like the project life cycle, we can map the process groups to the agile fractal – at the overall project level, at the release level and at the iteration level.

ANOTHER VIEW... of functional mapping between PMI processes and agile involvement

plan driven, plan modified, agile, agile, plan driven

paper: „Utilizing Agile Principles Alongside the PMBOK”, Mike Griffiths, 2004

Initiating Planning Executing Controlling Closing

USE AS IS • chartering and

identifying perliminary socpe

• explain where you will use agile to stakeholders

• organize workshops, seminars, presentations on agile thinking

USE W/ MODIFICATIONS • move to iterative

planning • use plan

refactoring to keep the pace with the project

• HIGH: switch from task to feature themes

• LOW: use iteration

USE AGILE • develop iteratively

and mitigate technical risks as we progress

• use meaningful metrics (features delivered and project time remaining)

• empower the team

USE AGILE • iterations review,

assist with project steering

• change requests, defects and risks prioritization

• controlling flow, look at the holistic view of the project to maximize the delivery

USE AS IS • closing processes

as defined in PMBoK to be considered

OR, JUST USE PMI – ACP ? big guns understand PMI and PM methodology. can PMI help us here?

this is just a certification: agile certified practitioner beware, on PMI PMBoK ver 5, January 2013, 616 pages, no mention of agile

note: again this is just a cert, one need to implement agile project management @the house

DOMAIN I DOMAIN II DOMAIN III DOMAIN IV DOMAIN V DOMAIN VI

VALUE DRIVEN DELIVERY • defining positive

value • incremental

development • avoid potential

downsides • prioritization

STAKEHOLDER ENGAGEMENT • stakeholder needs • stakeholder

involvement • stakeholder

expectations

BOOSTING TEAM PERFORMANCE PRACTICES • team formation • team

empowerment • team collaboration • team commitment

ADAPTIVE PLANNING • levels of planning • adaptation • estimation • velocity • throughput • cycle time

PROBLEM DETECTION AND RESOLUTION

CONTINOUS IMPROVEMENT

BLENDING OF WF AND AGILE? PROGRAM MANAGEMENT: organizing and coordinating several projects’ results into one deliverable that has the value to the organization

agile program management + traditional project mgmt

• traditional project nad agile program management wrapper around series of iterations driven to key milestones

• program management • helps make the between-teams risks transparent • collects and explains program status

• product owners manage what-to-build risk • protective bubble around the development team

note: this is very seriously noted at ALM 2012 Conference in Seattle

PROJECT MANAGEMENT @CORP one can find all forms of mix/match orgchart projects at the corporation

PROJECT MANAGEMENT IS STILL REQUIRED

• Agile must comply with the „Business Management System”

• Agile requires some type of Project Management System tailored to methodology

Note: „Agile & Project Management”, Michael Milch, 2011

Business Management System

PROJECT 2 PROGRAM1 PROJECT1

SUBPR 1 SUBPR2 PROJECT3 PROJECT4

AGILE

NONAGILE

so, how can corporations survive agile? send them to the movies... (or, three movies that they have to see...)

MOVIE No.1: JERRY MAGUIRE AGILE is about changing the way people work

you eat elephant one bite at the time there will be no support for a sudden changes to org practices

• it is not about the tools people use • it is not about sequences or units of work • it will take some time to accept the org change

• people will yell at you „SHOW ME THE MONEY”

• crucial: help team develop best practices, define DONE

note: have some friends help you out

MOVIE No.2: DUDE, WHERE’S MY CAR? PLEASE, explain stakeholders HOW you measure the progress

dont expect that CXO’s will understand that there are no milestones and project phases on the project

• primary performance indicators on an agile project: backlog size and velocity • please, explain that to the people in layman’s terms:

• Intervals to Complete (Backlog Size/Estimate Per Interval) EQ. Time • Burndown Chart EQ. Scope Delivery • Integration Management EQ. Steel Threads • Scope Management EQ. Working Software Demonstrations • HR Management EQ. Self Managed Teams • Communication Management EQ. Daily Stand-Ups

layman’s terms of layman’s terms: „describe a issue using words that the average individual can understand”

MOVIE No.3: BACK TO THE FUTURE even project managers are human, think what would be their role at next agile project

project manager’s next career step unfortunatelly, some of your team won’t fit agile

• now, it is all about people • most project / sales roadblocks are controlled by people that don’t see their

future implementing your project • can we find the role for good ol’ „corporate people at pmo”? • but in general, can we move people from Gantt chart?

• remember: from authoritarian approach to leading from within

note: you cannot develop company-wide plan to retire all project managers at once

and a book for THE END there is one book that could help you also

this is special edition for leadership development executives must drive organizational expectations, build teams and set priorities

• and this one enterprise understands. Messages like: • create a continuous process flow to bring problems to the surface • level out the workload • build a culture of stopping to fix problems, to get quality right the first

time • become a learning organization through relentless reflection and

continous improvement

layman’s terms of layman’s terms: „describe a issue using words that the average individual can understand

Q&A all the burning issues and questions

BIG THANKS!

more info ... if you feel like you want to know more or just for fun

ratko.mutavdzic@projektura.org dont bite, dont yell at you at all, so please, add me to your ... think network. tnx.

• WWW www.projektura.org • FBOOK www.facebook.com/projektura • TWEET www.twitter.com/projektura • EMAIL info@projektura.org

• but if it is really, really, really urgent and you really need to connect to people at

projektura ... • SKYPE projektura