This presentation outlines the spectrum of experiences from 8 years of SCRUM and KANBAN combined development of campus supporting software systems at a Swiss university.

1. 8 Years of Experience in SCRUM- and
KANBAN-driven Development of
Campus-supporting Software Systems
EUNIS 2018
mailto:christoph.baumgarten@fhsg.ch
mailto:christian.buttazoni@hsg.ch
mailto:andreas.mayer@hsg.ch
Christoph Baumgarten
Christian Buttazoni
Andreas Mayer
June 6, 2018

2. Agile SW Dev @ University of St.Gallen
2
● University of St.Gallen
 Swiss business school accredited by EQUIS and AACSB
 "Think tank & workplace" for ~8'500 students & ~2'900 academic staff
 The university's organization is heterogeneous, rather bottom up than
top down driven
 Holistic study approach: highly permeable study programs
 Goal: comprehensive digitization of student administration
► Requirements to underlying application landscape
are met by integrating standard & proprietary SW
● On-premise SW development & integration by inhouse SW dev group
as part of the university's central IT Services
 Short term & rapidly changing requirements, high quality expectations
► "What is specified is delivered" fails
► Agile approach to SW development: SCRUM & KANBAN

3. For projects: SCRUM @ University of St.Gallen
3

4. For projects: SCRUM @ University of St.Gallen
4

5. For projects: SCRUM @ University of St.Gallen
5
Daily business and change requests
are disturbing the team  KANBAN
Weekly Product Backlog
Workshop ~1h
CIP: Sprint Retro
Meeting ~1h
Daily I
~15min
Dedicated meetings,
strictly timeboxed
Requirements
 stories  tasks
Involve customers
while releasing: get
their acceptance
Explicit DoDs for
selected columns
Testing against stories'
acceptance criterions
Measurable
measures!
Sprint Planning
Meeting ~3h
Sprint Review
Meeting ~1h

6. Other: KANBAN @ University of St.Gallen
6

7. Other: KANBAN @ University of St.Gallen
7

8. Other: KANBAN @ University of St.Gallen
8
Pull principle:
constant flow
of work!
CIP: Biweekly
KAIZEN meeting
Biweekly Prio
Meeting ~15min
Measurable
measures!
Daily II
~15min
Limiting work in progress: Not more than n
stories in parallel
Dedicated meetings,
strictly timeboxed
Service classes sup-
porting priorization
- standard
- express
Tickets & CRs
 stories
Someone got bogged
down? Getting the
team together…
Involve customers
while releasing: get
their acceptance
Explicit DoDs for
selected columns
Testing against stories'
acceptance criterions

9. Staffing for SCRUM & KANBAN
9
● In FTE:
 Software engineering: ~11
 SCRUM master / agile coach: ~1
 Product ownership / IT service management: ~2
 Test management & engineering: ~2.4
 UX designing: ~0.6
● Maximum one SCRUM team at a time
● Alternating compositions of SCRUM and KANBAN teams
● During projects, keep teams constant

10. Remarks on Methodology
10
● It's worth to implement SCRUM and KANBAN according to best
practice  tailoring should affect detail level only
 E.g. no effort estimates on tasks, on stories only
● Explain SCRUM to stakeholders
 Relative meaning of story points and burndown diagrams…
 Explain risk reducing advantages of an agile approach
 University management
► Convince the university management to accept projects with a
clear budget but only a rough definition of the scope
► Integrate into any existing "traditional" PM frameworks; e.g.
redefine project manager's role – there's now a product owner…
avoid role duplication; adapt project reporting
 Invite stakeholders to Sprint Review meetings, make sure that
customers get and remain involved

11. Improved Tooling: Electronic SCRUM Board
11
Linked to MS TFS
(Stories)
SW: Eylean Board
HW: 85 in / touch screen / Win10

12. Improved Tooling: Electronic KANABAN Board
12
Linked to ITIL Tool
(Changes, Bugs)

13. Improved Team Maturity
13
● Behavioral maturity significantly increased
 True collaboration with customers
► Frequent customer feedback and changes in requirements: less
disturbing, but more as something useful to improve the product
► "We develop the product together with the customer"
 Continuous process improvement: Retro & KAIZEN meetings
► Important to have team members conducting an open and self-
critical discussion without management; led by SCRUM master
► Management is primarily informed about the derived measurable
measures; requires a fault-tolerant management culture

14. Improved Team Maturity
14
● Planning skills significantly increased
 Good understanding of the splitting of requirements into stories of
feasible size
 More reliable planning forecasts to customers and management due to
improved technical assessment skills
► Used estimation method: Planning Poker
 Self-responsibility regarding knowhow development and transfer that
helps ensuring permanent maintenance capabilities for all implemented
components

15. Teaching "Agile Web App Programming"
15
● Open to all Bachelor's subjects
● Learning objectives
 Build up practical SCRUM skills, understand SCRUM's success factors
 Develop state of the art web applications (angular, html5, nodejs, ts)
● Benefits
 Central IT true user of its own app's; increase int. acceptance & visibility
 University expands its curriculum in a crucial domain
● Structuring
 Students have different backgrounds  Briefly evaluate their IT knowledge
 Form heterogeneous SCRUM teams that cover all SCRUM roles
 Particular assignments ensure students share their individual learnings
 Initial acquisition of necessary basic knowledge, then implement step-by-
step a simple but appealing chat web app using the SCRUM methodology
 Sprints last one week, ending with a Sprint Retro and a Sprint Review in
Plenary; "customer": the course management

16. Outlook: How to continue?
16
● Limitations of current approach
 SCRUM's agility reduces to the macroprocess level: customer feedback
and releasing at sprint end only; story sizes must fit sprints
 SCRUM's overhead: sprint planning; unfinished stories are considered to
have failed – story implementation starts again from the beginning
● Customers tend to request more agility: continuous delivery, use
KANBAN for projects
 Keep the good elements of SCRUM: reviews with customers, product
backlog meetings to discuss stories in the team
 Adopt DevOps principles
► Cross-functional teams with end-to-end responsibility
► Further automate testing; "fail fast, fix now"
► Infrastructure as code; use cloud for scaling test & productive
environments
• Change to microservice-driven design to reduce internal bindings and
increase modularity & scalability of systems
• Use database-cloner and -anonymizers to automaticaly create testdata
without compliance issues

17. Optional Slides
17

18. Improved Tooling: SCRUM-Storycard Details
18
Storydescription
Estimate
Tasks
#TFS
Workitem