In the Division of Student Affairs at the University of Connecticut, the Applications Development team has been developing and delivering custom software using agile methods for over four years. In this session, we'll share our experiences and give you a behind the scenes look at how agile software development really works by walking you through how we translate the unique business needs of our clients into deployed software.

1. NERCOMP 2012
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 Technology
University of Connecticut
1

2. Who are we?
Student Affairs
Information Technology (SAIT)
Application development team
- 4 developers
- 1 team lead with several hats
2

3. Who are our customers?
• Center for Students with Disabilities
• Residential Life
• Office of Student Services and
Advocacy
• Dining Services
• Career Services
3

4. 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

5. Why write custom software for higher education?
• 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
5

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

7. It’s not that easy ...
• 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!)
7

8. Agile
8

9. What values are driving us?
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change 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

10. Values continued
10

11. Our secret sauce!
• Scrum: Agile Project management
• Good development practices
11

12. Let’s walk through the life of a feature
12

13. Meeting with the
customers
We want to hire a
notetaker...
It takes too much time
now!
Can you help us?
13

14. Mockup
14

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

16. Estimate the story
• The team estimates using a card game called planning poker!
16

17. Identify stories and commitment!
• Team commits to a group of stories that they will work on in the next 2 weeks.
17

18. Daily Standup
• Meeting every day... 15 minutes... standing up!
18

19. Development in progress...
19

20. 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

21. Source control and branching
• Central source code repository
• “Trunk”: always deliverable
• “Branch”: private copy of the trunk
21

22. 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

23. 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 number
and click the hire button, I should see the ‘notetaker hired’ message”
23

24. 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

25. Hire a notetaker screen
25

26. Tom is done!
• What does it mean to be “done”?
• Story is implemented
• Tests pass
• Coverage is good.
What’s next?
26

27. 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

28. 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. 29

30. Development practices in a nutshell...
• Source code control
• Simple design
• Automated tests
• Code review
• Continuous integration
30

31. Val accepts or rejects a story
• Last quality check
31

32. Demo and customer feedback
32

33. Story is live!
33

34. Repeat as needed!
• multiple stories (bricks)
• multiple sprints (rooms)
34

35. 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

36. 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

37. Another view on our practices
• show data!
37

38. Where do you start?
• One step at a time
• Make mistakes and learn from
them
• Enjoy the journey ... patience.
• Make it fun!
38

39. Acknowledgements
• Our team:
• Matthew Coolbeth
• Matthew Desmarais
• Michael Keating
• SAIT
39

40. Questions ?
Valerie Puffet-Michel
valerie.puffet-michel@uconn.edu
Thomas Wood
thomas.a.wood@uconn.edu
40

41. 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

42. 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

43. 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