March APLN: Agile development- Measure & Analyze by Garry Rowland

1

Agile Development

Are you Sure?

- Garry K. Rowland

2

Garry K. Rowland• Over 20 years of experience in

– Software Development– Programming– Quality Assurance– Process Engineering

• Worked in a wide variety of industries that include– Pharmaceutical– Public Records Information– Utilities (Nuclear)– Education– CAD Software Design– Retail - POS systems

• Perform Data & Process Analysis using Traditional and Bayesian methodologies.

3

4

Are you Agile?

5

Are you Agile?

Agility is the Goal. The debate about what development practices are or are not Agile is moot, Business stakeholders don’t care what your development process is called; they just want a return on their software investment. Focus on becoming more agile instead of becoming “Agile” and your business value will improve.

From the March 2009 Issue of “Better Software” magazine

6

Typical Agile Metrics

• Burndown Charts - A place to see daily progress to show monthly (per sprint) progress.

• Product Backlog - The requirements for a system, expressed as a prioritized list of product backlog Items. – These included both functional and non-

functional customer requirements, as well as technical team-generated requirements.

• Velocity - how much product backlog effort a team can handle in one sprint. – This can be estimated by viewing previous

sprints, assuming the team composition and sprint duration are kept constant.

7

Agile Metrics - What metrics are useful to whom?

8

Taiichi Ohno’s 7 Wastes (Lean Manufacturing)

1. Defects – Rework2. Inventory – Unassigned Backlog3. Overproduction – Low value “features, unused “hooks’4. Extra Processing – Unused documentation5. Unnecessary motion – Task switching, concurrent assignments6. Transportation – Handoffs7. Waiting – Delays for approvals, decisions & resources

9

Taiichi Ohno’s 7 Wastes (Lean Manufacturing)

1. Defects – Rework2. Inventory – Unassigned Backlog3. Overproduction – Low value “features, unused “hooks’4. Extra Processing – Unused documentation5. Unnecessary motion – Task switching, concurrent

assignments6. Transportation – Handoffs7. Waiting – Delays for approvals, decisions & resources

10

Data Mining

• Data without context is useless• Data is a snapshot in time• Data can be valid, reasonable & wrong• Text is a “Human expression”

11

Data without context is useless

“I once caught a Fish, this big”.

12

Data is a snapshot in time

• There is no failure, only feedback• Find metrics that can be

– Defined

– Measured

– Acted upon

• Agile is a journey not a destination, so the goal is to find & show improvement every time– Lessons Learned

– Once an Ideal Velocity is found, do you try to “improve” it?

13

Data is a snapshot in time - The Donald Crowhurst Effect

• Donald Crowhurst (1932–1969) was a British businessman and amateur sailor who died while competing in the Sunday Times Golden Globe Race, a single-handed, round-the-world yacht race.

• Crowhurst had entered the race in hopes of winning a cash prize from the Sunday Times to aid his failing business. Instead, he encountered difficulty early in the voyage, and secretly abandoned the race while reporting false positions, in an attempt to appear to complete a circumnavigation without actually circling the world.

• Evidence found after his disappearance indicates that this attempt ended in insanity and suicide.

Source: Wikipedia

14

Data can be valid, reasonable & wrong

15

Text is a Human expression

• If data is being stored in a text field, you may be missing vital information

16

Regression Testing

• Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, is a result of the changes made. It is performed when the software or its environment is changed.

17

Regression Testing


• What if your pass rate is 71.00%?

18

Regression Testing



19

Regression Testing



20

Defect Reporting Accuracy

• Illustrates Percent and Number of Valid Defects divided by Total Defects reported.– What if you have 26 issues that are “Not A Bug” (NAB)?

21

Defect Reporting Accuracy

22

A Bug’s Life

23

A Bug’s Life

24

A Bug’s Life

25

A Bug’s Life

26

Management by Variation

• High level overview of key components of a Project

• Identify variances from the “Norm”

• Goal is use of Objective Data to achieve Effective Cost Control

• Have the capability to “drill down” to pinpoint the weaknesses within the Process

27

• Additional Metrics to watch– Attrition– DRE Defect Removal Efficiency

28

Questions?

29

10 Things you might not know about Agile Development – Jeffery Payne

1. Agility is the Goal. The debate about what development practices are or are not Agile is moot, Business stakeholders don’t care what your development process is called; they just want a return on their software investment. Focus on becoming more agile instead of becoming “Agile” and your business value will improve.

2. Collocation of teams is not necessary. When building software, team rooms are definitely helpful in increasing agility but are not a showstopper. Distributed teams that focus on consistent, clear communication can use agile development practices to achieve business value.

3. Teams are still accountable. Implementing agile practices does not mean your software development teams are off the hook for on-time delivery. Agile greatly increases the visibility of day-to-day activities and drives teams toward higher productivity and accountability if implemented properly.

4. Business Sponsors needn’t be overburdened. Integrating business and domain knowledge into day-to-day project activities does not mean the process has to overburden your business sponsors. Business analysts can shoulder most of the day-to-day team interaction so business sponsors are called in only when really needed.

30


5. Unit Testing is non-negotiable. If you are not doing Unit Testing, you are not doing agile development. Unit testing is a cornerstone practice that makes other practices – such as continuous integration and refactoring – possible and valuable.

6. Agile software can be secure. There is nothing about agile development that results in insecure software. Agile done right integrates secure development practices and security assurances into all development and testing activities.

7. Agile is rigorous. Don’t be fooled into thinking that agile is a less-rigorous process than other development approaches. When done correctly, agile is a consistent, repeatable process with strong measurement of progress, risks, and productivity.

8. Gurus don’t have all the answers. Software succeeds or fails in the trenches where it is built. Many Agile coaches haven’t written a commercial software application in a decade. Trust and learn from those who do Agile, not just talk about it.

31


9. Architecture and Design are still necessary. You can’t refactor your way into initial architecture. Time must be spent during initial planning and iterations to get your architecture solid. From there, incremental development that includes refactoring can drive your software to completion.

10. Doing Documentation is OK. Many software products must comply with standards, regulations, and corporate development policies. There is no reason that Agile cannot be used to build these types of products as long as the appropriate documentation is created during the process.

From the March 2009 Issue of “Better Software” magazine

32

References

Jeff Payne - Payne is CEO and founder of Coveros, where he has led the startup and growth of the company. Prior to starting Coveros, Mr. Payne was Chairman of the Board, CEO, and co-founder of Cigital, Inc. Under his direction, Cigital became the leader in Software Security and Software Quality solutions, helping clients mitigate the business risks associated with failed software. With the company profitable and bootstrapped since its inception in 1992, Mr. Payne raised $4M in expansion capital in 2002 and another $1M in 2004 to cement Cigital as the industry leader in the Software Security and Software Quality market.

Taiichi Ohno - was a prominent Japanese businessman. He is considered to be the father of the Toyota Production System, which became Lean Manufacturing in the U.S. He wrote several books about the system, the most popular of which is Toyota Production System: Beyond Large-Scale Production.

ISTQB Board - http://www.bcs.org/upload/pdf/glossary-current.pdf

http://www.bcs.org/upload/pdf/glossary-current.pdf