Agile Software Development in Practice:Experience, Tips and Tools from the Trenches of Higher Education

Valerie Puffet-Michel (valerie.puffet-michel@uconn.edu)and Thomas Wood (thomas.a.wood@uconn.edu)

Student Affairs Information TechnologyUniversity of Connecticut

NERCOMP 2012

1

Who are we?

Student Affairs Information Technology (SAIT)

Application development team- 4 developers- 1 team lead with several hats

2

• Center for Students with Disabilities

• Residential Life

• Office of Student Services and Advocacy

• Dining Services

• Career Services

Who are our customers?

3

Outline

• Why write custom software?

• Challenges of software development in higher education

• Our secret sauce!

• Walk through “The life of a feature”

• What worked for us and what didn’t ...

• Where do you start?

4

• When you can’t always get you want (from a vendor) ...• Quality• Features• Timeliness

• ... you can get what you need!• The features you need when you want them• Opportunity to design a system: software, business process, integration

Why write custom software for higher education?

5

So ... we want to develop software, but ...

6

• In typical software projects:• Scope, resources, planning determined at start of the project ...• ... when you know the LEAST

• We face:• Limited resources• Diverse demands• Everything is important

(no economy!)

It’s not that easy ...

7

Agile

8

What values are driving us?

Individuals and interactions

Working software

Customer collaboration

Responding to change

over processes and tools

over comprehensive documentation

over contract negotiation

over following a plan

while there is value in the items on the right,

we value the items on the left more.

Agile Manifesto

9

Values continued

10

• Scrum: Agile Project management

• Good development practices

Our secret sauce!

11

Let’s walk through the life of a feature

12

We want to hire a notetaker... It takes too much time now!

Can you help us?

Meeting with the customers

13

Mockup

14

Clarify the story

• Val & the team have a conversation, clarify the story.

15

Estimate the story

• The team estimates using a card game called planning poker!

16

Identify stories and commitment!

• Team commits to a group of stories that they will work on in the next 2 weeks.

17

Daily Standup

• Meeting every day... 15 minutes... standing up!

18

Development in progress...

19

Conversation leads to just enough design

• Story as conversation

• What does it mean for a story to be “done”?

• Design just enough to implement the feature

20

Source control and branching

• Central source code repository

• “Trunk”: always deliverable

• “Branch”: private copy of the trunk

21

Tests

• We believe strongly in tests. • 2x as much test code as application code• Tests make us fearless• Tests give us executable documentation• Our tests are automated and easy to run

22

Two types of tests

• Unit tests

• “When a notetaker is hired for a class, the notetaker should be added to the list of notetakers for the class.”

• Functional tests

• “Given I am viewing the schedule for a prospective notetaker, when I check the box next to a class, enter a cell phone numberand click the hire button, I should see the ‘notetaker hired’ message”

23

Test Coverage

• Goal is to make sure every line of code is tested.

• All of the individual tests are collected in a test suite

• Coverage measures which lines of code are executed while a test suite run.

24

Hire a notetaker screen

25

Tom is done!

• What does it mean to be “done”?

• Story is implemented

• Tests pass

• Coverage is good.

What’s next?

26

The team reviews the code

• Change is distributed to team members for review• Why code review?

• shared ownership • increase quality• follow standards• cross training for free

27

Jenkins helps test the feature automatically

• Jenkins is a continuous integration server.• How does it work?

• When new code is committed to trunk, Jenkins runs the tests automatically, measures the coverage, and deploys the application so Val can try it out.

• Goal: • Automated builds that verify quality: • Make sure we still have working software

Work smarter, not harder!

28

29

Development practices in a nutshell...

• Source code control

• Simple design

• Automated tests

• Code review

• Continuous integration

30

Val accepts or rejects a story

• Last quality check

31

Demo and customer feedback

32

Story is live!

33

Repeat as needed!

• multiple stories (bricks)

• multiple sprints (rooms)

34

Challenges we faced

• Customer collaboration• Getting regular time with customers. • Getting customers to test the software.• Not having the right users in the room (e.g. students, maintenance staff)

• Development practices & estimation• Deployment cost• Code review bottleneck• Difficulty estimating uncertain stories

35

What works for us?

• Customer collaboration and feedback• Customer prioritizes the work, team only works on most important features.• We make change happen, flexible• We continually improve our practices.• Deliver software as we go (one brick at a time!)

• Team works on one project at a time • Management support and clear priorities set by SAITOC (Student Affairs IT

Oversight Committee)

• We have fun and love what we do. Everyone is happy!

36

Another view on our practices

• show data!

37

Where do you start?

• One step at a time

• Make mistakes and learn from them

• Enjoy the journey ... patience.

• Make it fun!

38

Acknowledgements

• Our team:

• Matthew Coolbeth

• Matthew Desmarais

• Michael Keating

• SAIT

39

Questions ?

Valerie Puffet-Michelvalerie.puffet-michel@uconn.edu

Thomas Woodthomas.a.wood@uconn.edu

40

Learn more• the agile manifesto: http://agilemanifesto.org/

• scrum• Intro to scrum - http://www.mountaingoatsoftware.com/topics/new-to-agile-or-scrum• Agile Project Management with Scrum - Ken Schwaber• Jeff Sutherland's blog: http://scrum.jeffsutherland.com/

• development practices• Practices of an Agile Developer - Venkat Subramanian, Handy Hunt• Extreme Programming Explained - Kent Beck, Cynthia Andres• Continuous delivery - Jez Humble, David Farley

• estimation, planning and stories• Planning poker: http://www.mountaingoatsoftware.com/topics/planning-poker• User Stories Applied: for agile software development - Mike Cohn• Agile Estimation and Planning - Mike Cohn

• from traditional project management to agility• The software Project Manager's Bridge to Agility - Michelle Sliger, Stacia Broderick• Agile Project Management: creating Innovative Products - 2nd Edition - Jim Highsmith

• certifications: • Scrum Master and Product Owner - Scrum alliance - http://www.scrumalliance.org/• PMI- ACP - http://www.pmi.org/Certification/New-PMI-Agile-Certification.aspx

41

Tools

• nose (www.readthedocs.org/docs/nose) - automated test framework

• Jenkins (www.jenkins-ci.org) - continuous integration server

• Pivotal Tracker (www.pivotaltracker.com) - agile project management

• Google Code Reviews (code.google.com/p/rietveld) - code review tool

• Subversion (subversion.apache.org) - version control system

42

Software stack

• Debian Linux (www.debian.org) - operating system

• Python (www.python.org) - programming language

• Pylons (www.pylonshq.org) - web framework

• SQLAlchemy (www.sqlalchemy.org) - object relational manager

• Microsoft SQL Server - relational database

43