agile simulation

Agile Project Management – SD Best Practices 2008

1

Presentation Copyright © 2008-2009, Agile For All, LLC. All rights reserved. Use by IACA permitted.

• Cell phones, pagers, PDA’s, etc. to silent

• If you have a question, please ask it. Don’t wait! It is better to answer the question while we are still in the same area than to go back.

• We will take a break after about 90 minutes

Before We Start

2Agile for Project Managers


2

• 30+ years of software industry experience

• Scrum Alliance Certified Scrum Coach (CSC)

• Bachelor and Masters degrees in Computer Science

• Roles included Tester, Developer, Dev Manager, QA Manager, Product Manager, Project Manager, VP…

• Started with agile in 1999

Bob Hartman (Agile Bob)

[email protected]

303-766-0917

Blog at www.agilebob.com



3

Discussion:

• Please introduce yourself including:

– Name

– Company and Role

– Agile experience

5

Who are you?

Agile for Project Managers

Discussion:

• This workshop is to learn about agile, while participating in an agile project

• In other words, this workshop IS an agile project!

• What should the goal be?

• How about:

6

Our Goal



4

• This is going to be just like an agile project• All of you represent certain roles

– Customer/Stakeholder– Team Members

• I represent certain roles– Product Champion– Team Member– Agile Project Manager

• We will go through an entire release, including planning, iterations, retrospectives, etc.

• Our iterations will each be 20-30 minutes in length, so we will be covering things VERY quickly!

How the Workshop Will Function


• In an agile project you need two things to get started on a project:– Vision Statement

– Prioritized Product Backlog

• Our vision statement will be:FOR the attendees of this workshop WHO want to learn

more about agile software development THEworkshop IS AN agile project THAT will help them understand agile with real examples.

UNLIKE other workshops about agile OUR WORKSHOP will teach agile by being agile.

Starting the Project



5

Vision statement template

9

From “Crossing the Chasm” by Geoffrey Moore


Our product backlog (not prioritized!)

10

Release

Iteration Title VotesExpectations of Agile

Why Consider Agile?

Agile Metrics

Agile Process Basics

Agile Principles

Agile People and Roles

Agile PM vs. Traditional PM

Agile Planning

Agile Requirements

Agile Testing



6

• Go from to

• Everyone that will work on the project should attend in order to have their input heard

• 1st part of meeting

• 2nd part of meeting ask questions

• Last part of meeting for initial planning– Non-core team members should use this

time to make sure their needs are addressed

Release planning meeting


Discussion:

• What should our release backlog look like for this workshop?

12

Release planning



7

• Purpose is to get ready to start coding iterations

• Gather people resources

• Get organized

• Identify early risks

Iteration 0


• Some definitions:– Release – Final output of the development process

– Iteration – Small piece of the development time. Fixed length, usually 2 weeks, but can range from 1-4 weeks

– Backlog – list of work items for the product, release or iteration

• Our risk today is that we may run out of time– We will limit each section to no more than 25-30 minutes

– That should give us time for 4-6 iterations during the workshop

– We will re-evaluate after each iteration to make sure we get “the right 10 pounds of stuff in our 10 pound bag”

Workshop Iteration 0



8

• Team, Product Champion and Scrum Master– Purpose is for team to make commitment for what will be

done during the iteration

• 1st part: Ask questions and size stories.Make initial guess at commitment

• 2nd part: Break down storiesTeam does this withoutProduct Champion

• 3rd part: explain commitment(based on prior velocity)

Iteration planning meeting



9

Discussion:

• What are some ways to define agile software development?

18

What Do We Know



10

Dilbert on agile

19

Dilbert knows agile!

Or, maybe not


Agile is…Building software in iterations

typically 1-4 weeksmost teams use 2 weeks

Teams work from a prioritized backlogprioritized by Product Ownerconsists of “user stories” of 1-3 days duration

Teams are self-organizing and self-directingagile project manager (Scrum Master) facilitates

meetings and removes impedimentsteams make commitments and work as a team

Every day starts with a daily stand-up3 questions answered by everyoneno one else allowed to participate

What others commonly say



11

Agile is…

building the highest value software…

with high quality…

as fast as possible.

A more purposeful definition


1. Project is approved (generally outside agile)2. Release planning meeting3. Iteration 04. Iteration planning meeting5. Execute iteration (daily stand-up meetings)6. Iteration demo and retrospective7. If release not complete go to step 48. Release9. Release retrospective10.Repeat

Typical agile project flow



12

Agile process diagram


Another agile process diagram



13

Agile Roles


Iteration – the basic unit of agile

26

Iterations create a “product increment” of “potentially shippable

software.” This means everything is working. It DOES NOT mean we

can get it wrong in an iteration and then fix it all up in the next iteration!!!



14

• Team and Scrum Master attend

– Others can attend but it is not necessary

– This is team time, others should not participate unless it is by agreement with the team

• 3 questions are answered by each person

– What did I do since we last met?

– What will I do before we meet again?

– What is blocking me?

Daily stand-up – Part I


• Best is to add 3 more questions at the end of the meeting– Do anyone have any tasks that need to be added?

– Does anyone have anything we all need to know?

– Do any follow-up meetings need to be scheduled?

• NOTE: this part of the meeting is NOT a strict Scrum/Agile practice. It just seems to make things work better! People not on the team can participate here, especially during the 2nd

extra question.

Daily stand-up – Part II



15

• Everyone on the team participates in part I• No one outside the team participates in part I• In part II only items that are necessary for the

entire team to know are addressed

• THIS IS NOT A STATUS MEETING!!! This is a time for the team to interact– Hold each other accountable for results– Work better together by helping each other– Together make sure they are on track to meet the

iteration commitment

Things to remember


• Everyone always follows the same rule for what to do next:– Go to the highest priority story and if you can do one

of the tasks, do that

– If you can’t do any of those tasks, find the highest priority story where you can do a task and do that

• Things are always being worked from the top of the list down, so highest value will be delivered as fast as possible

• These two things done together create “swarming” on stories

Assigning tasks – DON’T!



16

Usual method of assigning tasks

31

US1

US2

US3

Task 1 Task 2 Task 3



Bob

Jill

Don

Bob will do US1

Jill will do US2

Don will do US3


Usual method of assigning tasks

32

US1

US2

US3




Bob

Jill

Don

Bob will do US1

Jill will do US2

Don will do US3

Bob

Jill

Don



17

Stop here – Do we deliver value?

33

US1

US2

US3




Bob

Jill

Don

Bob will do US1

Jill will do US2

Don will do US3

Bob

Jill

Don


Swarming example - start

34

US1

US2

US3




Bob

Jill

Don



18

Swarming example – 1st tasks

35

US1

US2

US3




Bob

Jill

Don


Swarming example – 2nd tasks

36

US1

US2

US3




Bob

Jill

Don

Bob

Jill

Don



19

Stop here - Do we deliver value??

37

US1

US2

US3




Bob

Jill

Don

Bob Jill

Don


Discussion:

• What did we learn?

• Any changes to the rest of the release plan?

38

Retrospective

Return



20

Discussion:

• If someone asks you “Why agile?” how do you respond?

40

Why agile?



21

• Business case essentials:

– Bottom line dollars and cents

– Improvements

• For this business case we should include:

– Business value created quickly

– Creating better products

– Team dynamics

– Planning improvements

Building a business case for agility


• Stuffing envelopes can tell us a lot about agile

• What are the advantages of getting something released more quickly?

Adding Business Value Quickly – A Simple Example



22

Creating better products

43

Never Used45%

Rarely19%

Sometimes16%

Often13%

Always7%

Question: What percentage of software features are NEVER used?


Delivering business value quickly

44

Never or Rarely Used

64%

Sometimes16%

Often13%

Always7%

Question: If we get rid of the 64% of software that is rarely or never

used, what happens to our overall software development efforts?



23

Discussion:

• When does the customer know what they really want in a product?

• How can we help them know earlier?

• Does that sound agile to anyone???

45

Expectations


• Morale improves– Team succeeds more often– Teams work together– Teams empowered to succeed

• Failures are very limited– A single iteration– Correction happens immediately– Team fails together so no blame– Happens quickly rather than

bleeding to death from a papercut

Changes to team dynamics



24

• Retrospections for correction and improvement

• Accurate management visibility

• Better predictability leading to success

Planning improvements


Discussion:

• What other reasons exist for using agile?

48

Other Reasons



25

Discussion:



49

Retrospective

Return



26

• Based on lean manufacturing principles

• Often called Lean Software Development principles

• Form the backbone of all agile practices

• Ignore at your own risk!

Agile Principles


• Unwavering guides• Always good• Foundational• Never change

“Principles are underlying truths that don’t change over time or space...” Tom and Mary Poppendieck, “Implementing Lean Software Development – From Concept to Cash”

What are principles?



27

• Things we do• Fit the situation• Apply principles• Change as needed

“… while practices are the application of principles to a particular situation.” Tom and Mary Poppendieck, “Implementing Lean Software Development – From Concept to Cash”

What are practices?


This sums it up best

“Principles are underlying truths that don’t change over time or space, while practices are the application of principles to a particular situation.

Practices can and should differ as you move from one environment to the next, and they also change as a situation evolves.”

(entire quote from Tom and Mary Poppendieck’s book “Implementing Lean Software Development: From Concept to Cash”)

This section talks about PRINCIPLES



28

• Eliminate waste

• Build Quality In

• Deliver Fast

• Improve the System

• Defer Commitment

• Respect People

• Create Knowledge

Agile Principles in a Nutshell


• Following these principles avoids many of the errors that plague the software industry today

Why these particular principles?



29

Boiling it down to a single thought


Even better is…

58

This is at the heart of continuous

improvement – the heart of agile.

This is the “one big thing” to remember.



30

• Building in iterations

• Daily stand-up

• Automated testing

• Nightly build

• Iteration planning

• Product Champion (Product Owner)

• Release planning

• Retrospectives

Agile Practices vs. Principles


Discussion:



60

Retrospective

Return



31

Dilbert



32

Discussion:

• Are agile requirements different? If so, how are they different?

63

Agile Requirements


The prioritized backlog(s)

64

Product backlog

All possible features

in priority order

Release backlog

List of features for

a given release

Iteration backlog

List of STORIES

for an iteration



33

Making things “agile ready”

65

EPIC/FEATURE(EPIC:Reporting System)

Minimally

Releasable Feature

(MRF:Canned Reports)

Minimally Releasable

Feature

(MRF:Template Reports)

Minimally

Releasable Feature

(MRF:Direct Queries)

User

Story

User

Story

User

Story

User

Story

User

Story

Tasks Tasks Tasks

Notice the elimination of

waste (agile principle) by

not spending time on

pieces that aren’t needed

for the release/iteration.

Product Champion

creates these items

Product Champion and

dev team create these

items

Team

creates

these


User Story Template



34

Another way to look at it


Some rules for the backlog



35

Guidelines

69

15% of backlog is iteration ready as user stories

25% of backlog is in the form of minimally

releasable features

The rest of the backlog is still in the form of

epics or high level features

DO NOT BE OVERLY PRECISE ABOUT THIS!!! These are

just guidelines. Do whatever works best for the team.


Discussion:



70

Retrospective

Return



36

Discussion:

• How do we do testing today?

• How is that working for us?

72

Testing



37

• Gold standard for agile is that each iteration creates potentially shippable code, which means– All unit tests pass

– All acceptance tests pass

• To meet this standard means that testing needs to be done DURING the iteration, not after– Tests must be written before or concurrently with

developing the software

What does “done” mean?


Defining the types of testing

74

Acceptance Tests

Business Intent(Design of the Product)

UsabilityTesting

ExploratoryTesting

Unit Tests

Developer Intent(Design of the Code)

PropertyTesting

Response,Security

Scaling,…

from Brian Marick

Technology Facing

Business Facing

Sup

po

rt P

rogr

amm

ing

Cri

tiq

ue

Pro

du

ct

Automated(QA)

Manual(Anyone)

Automated(Developer)

Tool-Based(Expensive)



38

• Product Champion refines stories and acceptance tests from Release Planning meeting, a few days before the Iteration Planning meeting

• Developers/Testers add more detailed tests in the Iteration Planning meeting

• Developers/Testers continue to build out in the Iteration – failing tests until code is implemented

• Developers get tests to pass

• Becomes part of the Regression test suite when story is accepted

Timeline for Acceptance Tests


Build quality in (agile principle) in action

76

C

o

s

t

Time

Cost to fix defects based on when they are found

Finding and fixing defects as soon as they are created is much

cheaper than finding and fixing them further along in the process.



39

• We have to validate

– That we understand what is needed

– That we did what we wanted

– That the product is of sufficient quality

• We must push testing up early

– Tests improve the conversation between customers and developers

– Tests become executable specifications

Validation and testing


Remember…



40

• FIT: Framework for Integration Tests (html)

• FitNesse (wiki)

Open source tools for automated testing

fit.c2.com/

www.fitnesse.org/


Discussion:



80

Retrospective

Return



41

Measure appropriately

82

DILBERT: © Scott Adams/Dist. by United Feature Syndicate, Inc.

Remember, be careful what you measure!!!



42

• Need to know only a few things:– What items have been completed and what items are

not completed

– How are we doing in relation to our plan for the iteration

• Do not want to track metrics that will create waste– Processing raw data into status reports

– Generating reports that aren’t useful• Remember, you get what you measure (Dilbert comic)

Metrics During Iterations


Iteration status board

84

User Story

User Story

User Story

Task

Task

Task

Task

Task

Task

Task

Committed In Process Completed

Task

Task



43

Burn-down chart

85

0

10

20

30

40

50

60

70

1 2 3 4 5 6 7 8 9 10

S

t

o

r

y

P

o

i

n

t

s

Day

Burn-down Chart

Remaining


Burn-up chart

86

0

10

20

30

40

50

60

70

1 2 3 4 5 6 7 8 9 10

S

t

o

r

y

P

o

i

n

t

s

Day

Burn-up Chart

Committed

Completed

NOTE: This shows a very bad practice. A team should NEVER

drop scope from an iteration!



44

• Burn-up/burn-down charts at the release level

• Impediment list (and results)

• Retrospective action items, owners and results

Additional artifacts prior to release


• We often need to measure the performance of people

Performance Related Metrics



45

Measure UP

89

Span of

control (dev)

– items

directly

controlled

Span of influence –

must have teamwork

and rely on others to

succeed

Span of control (dev): Coded story points

Span of control (QA): Number of tests run

Span of influence: Features in the field

with no reported bugs in 90 days

Span of

control (QA)

– items

directly

controlled


Discussion:

• What other metrics could you use that make sense in an agile environment?

90

Metrics



46

Discussion:



91

Retrospective

Return



47

Agile (Scrum) roles

93

Users/Stakeholders

•Those that are going to

use the product or have

a vested interest in how

it turns out

Team

•The team that will create

the product

•Includes EVERYONE

that is part of product

creation

Agile Project Manager

(Scrum Master)

•Facilitates of meetings

•Removes impediments

•Runs interference for

the team (firewall for

team)

Product Champion

(Product Owner)

•Owner of the backlog

(prioritizes and makes

decisions)

•Represents users and

stakeholders when talking

to team

•Represents team when

talking to users and

stakeholders


• Scrum Teams are filled with people who have skills, not people playing roles

• The individuals on a team self-organize for the task at hand

• The basic unit is the “Teamlet” or “Work Cell”– The Teamlet has all the skills it needs (analysis,

development, design, test, documentation, …)

– It typically consists of 2-4 people to get all the skills “covered”

– It swarms on one thing at a time

Self-Organizing Team



48

• One Bite at a Time– Do things a little at a time, with planning, validation, and management

of the pieces.

• Validation Centricity– The activities of validation, verification and test are “more important”

than those of analysis, design, and construction; and that we must actively look for things that cause us to change.

• Avoid and Eliminate Waste– Work on those things with the most value; have retrospectives to

evaluate process, etc

• Risk Awareness– Base decisions on risk analysis and mitigation – requirements risk,

architectural risk, technical risk, quality risk, people risk, etc

• Let Business Value Lead– Decisions must be based on the product, not documented plans,

analyses, requirements, or designs. The process doesn’t lead.

“Good” Team Philosophies, Found in Agile


• There are also personal qualities we like to see in the members of our team. We call them the “team values”

– Play To Win

– Communication

– Cooperation

– Trust

Personal Qualities We Want



49

• Many people play "not to lose"

• Playing to win beats playing "not to lose" almost every time

• Symptoms of playing "not to lose"– Lots of paper

– Lots of meetings

– "by the book" development

– It's CYA time…

• Playing "not to lose" usually creates waste

Play to Win


• Communication is perhaps the most important aspect of software development

• Used for

– Planning

– Laying out scope

– Getting feedback

– Explaining paths taken

Why We Communicate



50

• We are a team – a group of individuals that work together to be better than any of its parts

• Communication between members of the team is absolutely essential

• But even more important are– Cooperation – the willingness to subvert ones own

interests to those of the team, and work together to achieve them

– Trust – knowing that other members of your team are doing the best they can to do what is good for the team

• No individual blame – the process allowed it, so improve the process!

Cooperate and Trust


• Removes barriers to help team become more efficient and productive

• Facilitates close cooperation and creativity across all roles and functions

• Helps team remain focused on doing the most important things

• Can play role of process coach or help the team evolve their process

• Keeps Daily Scrum/Standup on task and on track• Helps resolve the impediment issues list, provides

status

Agile Project Manager (Scrum Master)



51

Product Champion

101

Represents (is a champion for) anyone

that is not present during interactions that

occur throughout the process

Needs to…

Empathize with customers

Understand the technology

Know when to listen!


• Agile development is not obvious:– It relies on its people– It takes extraordinary discipline

• Your individuals must have personal values that support agility– Developers– Managers– Customers

• These values are crucial– Without them you have no chance with any process– With them you can make almost any process work

Remember, values are key



52

Discussion:



103

Retrospective

Return



53

• You will release more software faster– You will release the highest value software as quickly as possible– More code will NOT be written in less time, but when you are

continuously releasing high value software it APPEARS that you are going faster

• Agile doesn’t need any documentation– The phrase to keep in mind is “just enough, just in time” and

this applies to most agile myths

• The developers run the show in agile– The developers follow the rule of finding the highest priority

task to work on and doing that– The Product Champion role defines the priorities, not the

development team

Common myths about agile


• The team will have a lot of questions– Questions should generally be funneled through a small

number of people

– This is where it is very useful to have a coach!• The worst thing to do is to try and make up an answer on the fly

• Even if you are “somewhat sure”, use your coach

• The team will want to know how/when they will be getting started with what they learned– This needs to be communicated clearly

– There will be some questions about how other groups are going to be integrated – again, communicate clearly

Immediate expectations



54

• Planning will be completely different– People will be uncomfortable with new methods– Stick with it, this stuff really does work!

• There will be some confusion– This is entirely normal!– Work through it and improve your understanding of

the process– Again, get your coach involved if there are significant

issues

• Don’t trust the results of this first iteration!– It is the first time people are doing this and it will

almost certainly be wrong

Iteration 1


• The bad news: results may not be what you expect– Iteration 1

• Team will likely only achieve 65% of what they believe they will achieve

• Plan on this and only allow the team to commit to about 65% of what they think they will be able to complete

– Iteration 2• Percentage of achievement is likely to be 80% of what the team believes

they can complete

– Iteration 3• Percentage increases to approximately 90%

– All of these iterations• Warts in the current system and assumptions will be exposed

• There is no place to hide the elephant in the room!

• The good news: things will continue to improve!

Iterations 1-3



55

• After the 3rd iteration the team should be able to have an accurate assessment of how much work they can do in each iteration

• It is important to use “yesterday’s weather” when deciding how much work can be done in an iteration

• Teams will generate the same amount of software as they did previously, but…– The software they are creating will be more in line with

expectations... assuming they are following what they learned

– The software should be of higher quality if developers and testers work together in an agile way

After iteration 3


• It is common for the process to degrade over time– We don’t really need to do that part…– It takes too long to do that…– Why do we want to keep doing that…

• DO NOT LET THIS HAPPEN!– The process should be improved, but that does not

mean removing essential pieces – that is NOT improvement

– If there is a temptation to remove pieces of the process, examine the agile principles and determine how else to solve the same problem

Long-term



56

• What teams generally experience– Anywhere from 25-50% improvement in productivity

• Some teams see as much as 300% improvement!• But be careful how this is measured

– Often teams are producing the same amount of software in terms of lines of code generated

– The features they are adding are the right features at the right time, which means… overall to get a release they generally need to create fewer features

– Higher morale• They are succeeding and responding to change

• What organizations generally experience– Software is created more quickly because… fewer

features need to be created to satisfy the customer

Potential results


What others are seeing



57

VersionOne Survey Results (2008)

113

Improvement Noted >10% improvement >=25% improvement

Increased productivity 89% 56%

Reduced software defects 84% 56%

Accelerated time-to-market 83% 54%

Reduced cost 65% 30%

Survey asked people: Please try to estimate SPECIFIC IMPROVEMENTS

you have actually realized from implementing Agile practices.

Source: VersionOne 2008 State of Agile Development Survey

NOTE: All 2008 data is within 2% of 2007 data implying these numbers are not

one-time anomalies

Biggest causes of company-wide agile failure:

Company philosophy or culture could not be overcome – 23%

Lack of experience with agile – 21%


Agile is a Proven ApproachSome Agile Companies (there are MANY more)


http://images.google.com/imgres?imgurl=http://www.pennmanor.net/schools/hs/canady/Images/Adobe-Logo.jpg&imgrefurl=http://www.pennmanor.net/schools/hs/canady/&h=343&w=300&sz=20&tbnid=UJ6OeziRNn7RCM:&tbnh=120&tbnw=105&prev=/images?q=adobe+logo&um=1&start=1&sa=X&oi=images&ct=image&cd=1

http://images.google.com/imgres?imgurl=http://www.lpds.sztaki.hu/dapsys/images/hp_logo.jpg&imgrefurl=http://www.lpds.sztaki.hu/dapsys/index.php?m=14&h=719&w=866&sz=45&tbnid=S_6SQ1FpkNEZBM:&tbnh=120&tbnw=145&prev=/images?q=hp+logo&um=1&start=1&sa=X&oi=images&ct=image&cd=1

https://www.eligibility.nedelta.com/index.html

http://www.rbauction.com/index.jsp?WT_svl=home_img

http://www.mapquest.com/


58

Discussion:



115

Retrospective

Return



59

• In preparing for battle I have always found that plans are useless, but planning is indispensable,”

– Dwight D. Eisenhower

Multi-Level Planning in Agile

ProductBacklog

ReleaseBacklog

IterationBacklog

Release Planning Iteration Planning


• Exist at 3 levels:– Product backlog – everything that might go into the

product

– Release backlog – everything that is currently committed for a release of the product

– Iteration backlog – everything that is committed for the current release

• The Product Champion OWNS the backlogs!!!

• Each backlog is kept in priority order at all times based upon the best information currently available

The Prioritized Backlogs



60

• Agile is all about adapting to change, and without constant reprioritization it is impossible to adapt

• Does it make sense to develop iteratively, learn something, then not reprioritize based on what was learned?

• Let’s look at a simple example of this in practice…

Why Prioritization is Important


Starting Feature List (non-agile)

120

Feature 1

Feature 2

Feature 3

Feature 4

Feature 5

Feature 6

To be implemented Completed



61

At Project Completion

121

Feature 2

Feature 5

Feature 1

Feature 3

Feature 4

Feature 6



At Project Completion

122

Feature 1

Feature 2

Feature 3

Feature 4

Feature 5

Feature 6




62

What Was Actually Desired

123

Feature 1

Feature 2

Feature 3

Feature 4

Feature 5

Feature 6



What Was Actually Desired

124

Feature 1

Feature 2

Feature 3

Feature 4

Feature 5

Feature 6


Feature 7



63

Why Reprioritization is Important (start list -agile)

125

Feature 1

Feature 2

Feature 3

Feature 4

Feature 5

Feature 6



1st Iteration

126

Feature 1

Feature 2

Feature 3

Feature 4

Feature 5

Feature 6




64

Reprioritize After Iteration

127

Feature 1

Feature 2

Feature 3

Feature 4

Feature 5

Feature 6



2nd Iteration

128

Feature 1

Feature 2

Feature 3

Feature 4

Feature 5

Feature 6




65

Reprioritize After Iteration

129

Feature 1

Feature 4

Feature 2

Feature 3

Feature 5

Feature 6



3rd Iteration

130

Feature 1

Feature 2

Feature 3

Feature 4

Feature 5


Feature 6

Feature 7



66

3rd Iteration

131

Feature 1

Feature 2

Feature 3

Feature 4

Feature 5


Feature 6

Feature 7


Discussion:

• How can we properly prioritize our backlog?

132

Prioritizing



67

The bottom line on prioritization


• Customer value (what is it worth to customers)

• Internal value (non-functional items)

• Business risk (how bad is it if we don’t do it)

• Technical risk (if we do it how risky is it)

• Business advantage (what can we gain from it)

Components of business value



68

• Other pieces can be added to the basic components of business value

• Somehow they have to be correlated in a way that allows ranking by business value

• Any ideas???

It is still a black art


Sometimes simple works well

136

Business Value Calculation

Story Customer Internal Biz risk Tech risk Biz Adv Biz Value

Reporting system 60 10 2 1 3 420

Admin section 40 30 3 3 1 490

Startup wizard 90 0 4 1 2 630

Server O/S upgrade 10 90 2 4 1 700

(Customer value + Internal Value) x (Biz Risk + Tech Risk + Biz Adv)

BUT… don’t rely just on numbers. Use your brain and make good

business decisions based on what you know. Numbers only guide.



69

An important point


Discussion:

• When are we done?

• Feature driven, date driven, or something else?

138

Planning



70

Discussion:



139

Retrospective

Return



71

Discussion:

• What do traditional project managers do?

141

Being a PM


• Based on command and control

• Heavy on planning

– Gantt and Pert chart centric

• Directs the work of the team to match the plan

• Stereotype is a person that drives the team

Traditional project manager



72

• Supports the team rather than driving the team

• Removes impediments for the team

• Represents the team to those outside the team

• Lets the team solve their own problems

– Coaches the team and helps them improve

Agile project manager


• In Scrum this role is called Scrum Master• This role facilitates all meetings

– Release planning– Iteration planning– Daily stand-ups– Retrospectives

• Responsible for removing impediments– Responsible for does not imply they have to do the work to remove the

impediment!– This is a BIG piece of the role

• Very short timeframes in agile• Short delays removing impediments have drastic effects

• Supports the team by helping however necessary– Communicates on behalf of the team to allow them to focus– Keeps the team true to the agile process– Makes sure the team keeps grinding away and making progress

• Tracks and reports status

More specifically…



73

• Rather than plan, instruct and direct, the agile project manager facilitates, coaches and leads.

- scrumalliance.org• One who uses the Scrum framework, by focusing on

facilitation, leadership, report building and communication in place of prescribed command as process control.

- wiki.answers.com• Unlike traditional project manager roles, the ScrumMaster

does not assign individual tasks to the developers or QA but rather the development team self-organizes on each iteration and determines who will do each task.

- Hector Correa in CoDe Magazine

What others say


• Making spaghetti can teach us a lot about why directing is harder than letting the team solve problems on their own.

Demonstration



74

Discussion:



147

Retrospective

Return



75

• Coding is finished, now time for release related activities which may include…– Final verification testing

– Property tests not done during the iterations (due to cost or complexity). Things like security testing, compliance testing, response time testing, scalability testing, etc.

– Complete documentation

– Complete training

– Complete rollout to production servers

• Celebrate!

Normal Agile Release


• Any quick questions on what we covered?

• What did we not cover that we could cover very quickly right now?

Workshop Release: Tie Up Loose Ends



76

• Anyone can attend– Team members are REQUIRED!

• Start with 5 easy questions1. What did we do well?

2. What did we do less well?

3. How did we improve?

4. What actions can we take to address things we did less well (and who will own them)?

5. What can we do to improve next iteration (and who will own these items?

Retrospectives



77

• Create a document or wiki page with the results of every retrospective– Create knowledge (agile principle) to help others

• “How did we improve?” question should at least address action items from previous iteration

• Hold people accountable for items they own, BUT DON’T BLAME PEOPLE!– The process allowed it to happen– Change the process so it doesn’t happen again

• This is a primary way for the team to improve so use it as effectively as possible

Remember


• Address a recurring problem– If the same problem keeps coming up, use the 5 why’s

to get to the root cause

• Ask additional questions– What would we change if we were in charge?

• Interestingly, the team is more in charge than they believe and many of these items can be implemented

– What types of feedback have been most useful?

– What one question would we like users to answer?

– What risks do we need to identify right now?

• Think outside the box – don’t limit the team!

Going further



78

Discussion:

• How did this format work?

– What went well, what didn’t go so well?

• Did we get “the right 10 pounds of stuff in our 10 pound bag?”

• What should I change for next time?

155

Our Retrospective



79

agile simulation

Technology

project managers126

project managers7

project shouldattend

project managers84

project managers21

geoffrey moore agile

role agile experienceagile

project managers11 discussion