Download - "Agile Project Management": Is it an Oxymoron?

© 2014 NUS. All rights reservedAgile Seminar/V 1.0

Agile Project Management –Is it an Oxymoron?

Jagadeesh BalakrishnanInstitute of Systems Science

National University of Singapore


Outline of the session

Why Transition to Agile?

Is there a Agile Silver Bullet Methodology?

Binary Thinking : Traditional or Agile Planning?

Is Agile PM an Oxymoron?


AGILE – To be or Not to be?

Why Transition to Agile?


1. Build ability to “Change”

Agile is a way of developing software that’s all about planning for and expecting change!

“ It is not the strongest or the most intelligent who will survive but those who can best manage

change”- Charles Darwin


2. Agile Projects – Promotes Chaos or Order?


Copyright © 2010 AgileInnovation

2. “Chaordic” Agile Projects


3. Handle Requirements “Uncertainty”

You have to meet your friend who lives in KL. You start on a Saturday afternoon in your car to KL from Singapore; On the way to KL, you find that there is a bridge you need to cross . You start

climbing the bridge. It would normally take 5 minutes to reach the crest of the bridge from the

entry at the speed of 65km/h.

Please find out how much time it would take to cross the bridge in total.


4. Deliver “ Value” early


Agile approach delivers value early compared to a waterfall approach!


5. Release Software “frequently”

How frequently do you release software?• Once a day

• Once a week• Once a month• Once a year

• Once in several years?

Jez Humble Quote:‐ “In the mid 2000s, a number of very fast‐moving companies were able to change the way software development happened. ‐ Flickr ‐ being able to do multiple deployments per day.‐ This ability to move very quickly threatens existing organizations who are unable to adapt”


Source : John Allspaw: “Ops Metametrics” http://slidesha.re/dsSZIr

Benefits of frequent release are constant customer feedback & reduced risk of release!

5. Release Software “frequently”


6. The Agile “belief system”

• You have to be an Agile believer!

• Agile doubters knead out “Agile can’t work stories”• Our business users will never get involved in project actively• We have a fixed contract• We can’t allow teams to self organize as it will result in chaos• We are already successful using traditional waterfall • There is no way to understand requirements upfront• There is nothing scientific about agile – its against process

culture


Reasons for Transition to Agile:1. To Build ability to Change2. To Manage Chaordic projects3. To Handle Requirements uncertainty4. To Deliver Value early5. To Release Software frequently6. Agile Belief System

Summary ‐ Reasons for Transition to Agile


Where is my PRINCE 2 / PMP Equivalent?

Which Agile Methodology is Best?


SCRUM – Management Driven

Source: Scrum Primer

Requirements ManagementRelease ManagementMonitoring


Feature Driven Development – derived from traditional methods

Source: http://www.skillresource.com

Management and Development focusedObject oriented, unit testing, design sessions, code reviewsDesign first, upfront plan


DSDM Process Overview

Design& Build

Iteration

AgreeSchedule

CreateDesign Prototype

IdentifyDesign Prototype

ReviewDesign

Prototype

Implementation

Implement

ReviewBusiness

TrainUsers

User Approval &User Guidelines

Review Prototype

FunctionalModel

Iteration

Agree Schedule

CreateFunctionalPrototype

IdentifyFunctionalPrototype

Feasibility

Business Study

Management and DeliveryFunctional Model IterationDesign and Build iteration


Few Agile Frameworks – Brief Comparison

Model Selection CriteriaSCRUM Team Size : 6‐8

Scalability : Use Scrum of Scrums approach Team Dynamics : Colocation preferred User Involvement : High Iteration length : 2‐ 4 weeks Nature of Requirements : Complex

FDD Team Size : Can be of any order Scalability : Scalable for large, distributed agile teams /projects Nature of requirements : Should be breakable in to features Approach : Favors object oriented approach to development

DSDM Team Size : 2 ‐6 Scalability : Multiple team groups of 2‐6 members within the same project Nature of requirements : Should be able to create prototypes for the system

during early stages of the project Approach : Use whenever feasibility and business study are necessary


Which Agile model(s) for our Organization?Jim High Smith's Advice : Hang out with a few agile models. Your

organization will know what you like soon. Agile is a culture NOT a process!


Model Dilemma : What’s popular vs. What’s the future?

19

Take the Quiz :“ Who amongst the below were NOT used for promoting Cigarette advertisements in USA?”

A - Small Baby B – Pregnant Woman C – Doctors D – Supreme Court Judge

Most popular models may not be the perfect solution for your organization.

Testing out multiple models and adapting it to the work environment is the fundamental essence of Agile.

Case : Scrum – FDD – DSDM – My own model?


Agile Ecosystem or Methodology?

Ecosystems are about its inhabitants. Methodologies are about the processes. Methodology driven culture is the opposite of Agile culture!

Remember: 1. Articulate agile values & principles for your organization first.

2. Remember that popular agile methodologies are just barely good enough. Use it as it is at your own risk.3. Don’t search for solutions in methodologies. There is no silver bullet there!

4. Remember Cockburn : Larger teams need heavier methodologies!


Binary Thinking – Traditional or Agile Planning?


Planning at Organization Level : Stages of Agile adoption



Planning at Project Level : Plans as Hypothesis or a Fixed Goal?

“Plan the work & work the plan” approach fails when we are not even sure where we are headed!

Don’t try to find processes that eliminate change. Build processes that respond to change.

A plan isn't a prediction. It is there for collaboration. It’s there to help make go /no go decisions. Its not there to dictate.


Find your Balance Points…

Try this Agile Value interpretation exercise:

Could we have a successful project by delivering documentation without working software?

Could we have a successful project by delivering working software without documentation?

Note : Delineate the extremes, the end points so that organizations, teams & individuals can find their own balance points – Jim High Smith

Companies must determine what level of agility they require to remain competitive…


The Good, Evil, Great in Agile Projects…

Agility is not a fancy name for lack of planning & ad hoc-ism. Agile projects still plan. They just understand the limits of planning. Programmers become skilled & agile from long hours of training and

mentoring. Agility in fact requires discipline and skill. One has to be skilled before becoming agile ( Picasso) If you want to explore & innovate, give room for some inefficiencies


Is the role of Project Manager non existent in Agile?


Complications in Agile Project Management?

User involvement

Fixed end date

New /old staff

Multi location project

Many Component projects


Traditional PM or Agile PM ‐ Clash of Titans…

PMPs versus APMs?? “Ramrod Project Managers” are extremes and

never promoted either by traditional or agile project management.

Agile Projects need to be budgeted for and controlled and hence need supervision.

Not minding anything but the team and Agile principles can create a bubble that could burst at any moment.

ITS ABOUT HOW AGILE YOU WANT TO BE NOT ABOUT WHICH APPROACH IS BETTER!


Agile Project Management is definitely NOT an Oxymoron!

There is no Agile Silver bullet out there…

Organizations need to carefully build their own Agile bridges by asking “How Agile

should we be?”.


Be Agile…