Applying Agile Practices to Space-Based Software Systems

Applying Agile Practices to Space-Based Software Systems

Arlene Minkiewicz, Chief Scientist [email protected]

© 2013 PRICE Systems, LLC All Rights Reserved |

Decades of Cost Management Excellence

1

Agenda  Introduction  Agile Software Development  Agile in Space  Size and Cost Estimation for Agile Software Development  Conclusions

© 2013 PRICE Systems, LLC All Rights Reserved |

Decades of Cost Management Excellence

2

Introduction  Agile development practices have enabled organizations to deliver quality software that optimizes

customer satisfaction – But is agile for every type of software?  Space and other mission critical software have high reliability, fault tolerance requirements with

strict safety and performance criteria  Organizations developing space based software are looking for ways to do development Faster,

Better, Cheaper  Can the application of agile practices to space software development help deliver within the

safety and performance requirements for such systems

© 2013 PRICE Systems, LLC All Rights Reserved |

Decades of Cost Management Excellence

3

Agile Manifesto – February 2001  We are discovering better ways of developing software by doing it and helping others to do it.

Through this we have come to value – – – –

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

 All agile projects adhere to this manifesto  All agile projects share a common set of principles  Each agile project uses a set of agile practices to implement these principles.

© 2013 PRICE Systems, LLC All Rights Reserved |

4

Decades of Cost Management Excellence

4

Agile Software Development  Agile Software Development – Usable chunks of software are developed in short periods of time (sprints, iterations, etc.) – Requirements are translated into User Stories and become the project backlog – User stories deliver business value and are small enough to be completed in an iteration – Customer works with the team and reviews software regularly – Each iteration focuses on the User Stories that are currently highest priority of the customer – Priorities may shift from iteration to iteration – Agile teams expect and embrace change

© 2013 PRICE Systems, LLC All Rights Reserved |

5

Decades of Cost Management Excellence

5

Agile vs Waterfall  Agile practices are gaining in popularity.

– Recent Forrester Study shows 50% of respondents claim a mature adoption of agile (“How Agile is Your Organization?, April 30,2012)  Agile provides a great way for software development organizations to deliver quality

software in a predictable fashion  Agile may not be the best paradigm for all types of software development or in all

project phases  Using agile techniques for projects focused on architecture design or redesign may be

problematic  Many organizations use a combination of agile and plan based techniques depending

on goals of current release  Certainly is room for such a hybrid process

© 2013 PRICE Systems, LLC All Rights Reserved |

6

Decades of Cost Management Excellence

6

Agile Principles  Customer satisfaction through frequent deliveries

and customer involvement  Focus on business need and business value  Time boxed development  Constant collaboration and communication  Sustainable pace  Adaptation to change  Self Organizing Teams  Collective ownership and responsibilities  Commitment to measurement © 2013 PRICE Systems, LLC All Rights Reserved |

7

Decades of Cost Management Excellence

7

Common Agile Practices  Pair programming  Continuous integration with automated

testing  Test Driven Development  Daily Stand-up meetings  Co-located teams  Code refactoring  Small releases  Customer on team  Simple Design © 2013 PRICE Systems, LLC All Rights Reserved |

8

Decades of Cost Management Excellence

8

Agile in Space  Space and other mission critical systems have high reliability, fault tolerance requirements with

strict safety and performance criteria  Mission success likelihood greatly increased with integrated, effective application of technology

and process.  Key principles to be applied:

– Effective requirements management and analysis – Reusable component libraries – Object oriented methodologies – Prototyping – Quality Assurance  According to Alistair Cockburn (one of the original agile proponents) “small projects, web

projects, exploratory projects, agile is fabulous; it beats the pants off of everything else, but for NASA, no”  But maybe there is a middle ground

© 2013 PRICE Systems, LLC All Rights Reserved |

Decades of Cost Management Excellence

9

Agile in Space – a hybrid solution?  Agile practices for consideration: – Small teams evolving product in small visible steps – Daily stand up meetings – Pair programming – Continuous automated testing – Test driven development – Collaborative planning (include the customer)

 Agile practices most likely to be inappropriate: – Evolving requirements – Little to no documentation – Refactoring

© 2013 PRICE Systems, LLC All Rights Reserved |

Decades of Cost Management Excellence

10

Agile in Space – Case in Progress  NASA Ames – Mission Control Technologies – Adopted a hybrid agile solution – Have segregated activities constrained by mission criticality from more standard development activities

 Agile practices they have incorporated include: – Shortened delivery cycles that customers can touch and evaluate – Direct on-going interactions between customers and developers – Daily builds with automated testing

 Requirements are dealt with on several levels – Mandated by government, control center, or other nonnegotiables are handled outside the customer feedback look – Other requirements are handled more agily

© 2013 PRICE Systems, LLC All Rights Reserved |

Decades of Cost Management Excellence

11

Agile in Space – Case in Progress  Other project details – Iterations are kicked off with demonstration and retrospectives – Issues are presented, discussed and ranking occurs – Issues are not added to iteration until team understands well enough to estimate – Development and design team work together on design (design documents are developed and maintained in parallel to the agile ‘production’ activities – Non trivial development tasks are documented as to approach selected and why – Features are tested • By developers in lab environment • Customers test features as they roll out outside the operational environment (to determine satisfaction with features and provide feedback) • Final verification occurs in full operational environment outside of actual mission

– Automated builds with testing occur daily - test failure closes the code repository until the failure is resolved.

 MCT is no different than other agile development efforts in that the

agile process has adapted with the projects based on what works for the development team and meets NASA Requirements © 2013 PRICE Systems, LLC All Rights Reserved |

Decades of Cost Management Excellence

12

Agile Estimation  Frequently Asked Questions – How do I estimate size for an agile project when the team is working with Story Points? – What other cost driver changes are indicated for agile development?

© 2013 PRICE Systems, LLC All Rights Reserved |

13

Decades of Cost Management Excellence

13

Agile Size Estimation  Estimation goals are different at different stages of a project  Early on in the project is when estimation is most challenging since less

detail is available – Agile teams often will use something like t-shirt sizes to discuss feature sizes with non technical folks to facilitate estimation discussions  Agile teams do lots of their own estimating

– At the start of each iteration, the team breaks the current User Stories into tasks and estimates effort for each task – For each Story the team determines the number of Story Points using an arbitrary system agreed upon within the team • Planning Poker, Fibonacci numbers (0,1,2,3,5,8,13….) • Story Points are relative ( a story of 2 points will take twice the time as one with 1)  How does one go about translating story points to something more

concrete to support estimation early in the lifecycle © 2013 PRICE Systems, LLC All Rights Reserved |

14

Decades of Cost Management Excellence

14

Agile Size Estimation  Story Points are Notional and don’t trend with effort nicely  In the context of a parametric model – Story Points really

combine two typical drivers – Software Size – Complexity of the functionality

© 2013 PRICE Systems, LLC All Rights Reserved |

15

Decades of Cost Management Excellence

15

Fortunately Agile Teams collect metrics

© 2013 PRICE Systems, LLC All Rights Reserved |

16

Decades of Cost Management Excellence

16

Agile Size Estimation  Study of PRICE’s agile

development data found no correlation between story points and software size (SLOC) or effort  Did find a significant

relationship between Software Size and Complexity pairs and effort/hr.  Calibration of Functional

Complexity to agile data resulted in interesting size/complexity relationship © 2013 PRICE Systems, LLC All Rights Reserved |

17

Decades of Cost Management Excellence

17

Agile Size Estimation  From PRICE Data we developed a

methodology to estimate size complexity pairs from Story points and the teams assessment of complexity relative to the data set.  This methodology transcends tool

but needs to be informed by data from the agile team delivering story point estimates  This methodology appeals to agile

thinking folks but supports parametric estimates with relevant cost drivers

© 2013 PRICE Systems, LLC All Rights Reserved |

18

Decades of Cost Management Excellence

18

Agile Cost Drivers  The fact that a project is agile is not a cost driver.  There are common agile practices that, if employed by an agile

team should have cost/effort impacts  It is important that the estimation team determine which agile

practices apply  For teams early in agile adoption, there are likely to be

productivity issues as new practices are adopted

© 2013 PRICE Systems, LLC All Rights Reserved |

19

Decades of Cost Management Excellence

19

Agile Cost Drivers  Agile teams tend to be highly skilled

– Hard to be a slacker in an agile environment – Working closely with high skilled team members, new members of the team are quickly brought up to speed – Input parameters indicating team experience would be affected  Agile teams tend to have tool sets that are more sophisticated than the average team

– Overhead associated with being agile – backlog maintenance, agile metrics collection, maintain user stories and tasks, etc. – Input parameters around tools or automation would be affected

© 2013 PRICE Systems, LLC All Rights Reserved |

20

Decades of Cost Management Excellence

20

Agile Cost Drivers  Co-location of teams should impact productivity positively

– Culture of interruption – but in a good way – Questions are answered in real time – Red tests get fixed right away – Co-location tends to increase the cohesion of the team – Co-located stakeholders and Subject Matter Experts (SMEs) make the team function more like an IPT – Well run daily stand up meetings also impact productivity – Input parameters indicating distribution of team locations, communication, IPT or team cohesion would be affected

© 2013 PRICE Systems, LLC All Rights Reserved |

21

Decades of Cost Management Excellence

21

Agile Cost Drivers  Continuous integration with automated testing should

increase the productivity for test and integration – Code is checked in frequently and builds are run and tested either on code change or in regular increments (hours, not days) – Red tests raise red flags and someone on the team steps up – Since little code was changed problem is easy to isolate – Since the change was recent developer more likely to remember context – Fix should occur quickly – Input parameters focused on integration testing complexity, issues would be affected.

© 2013 PRICE Systems, LLC All Rights Reserved |

22

Decades of Cost Management Excellence

22

Conclusion  Agile development practices are not equally valid for every type of projects  Mission success for space based software projects may be compromised if a

full blown agile process is applied  But remember that agile is a paradigm, not a methodology  An agile methodology can be customized to the development team and the

type of software being developed  Such a hybrid process could help achieved Better, Cheaper, Faster.  Agile methodologies recommend many practices that should be considered as

potential cost drivers  Estimation requires an understanding of the software being developed and

the environment it’s being developed in.

© 2013 PRICE Systems, LLC All Rights Reserved |

23

Decades of Cost Management Excellence

23

Questions

[email protected] m

© 2013 PRICE Systems, LLC All Rights Reserved |

24

Decades of Cost Management Excellence

24