Last month @maubagnato and I completed our first experience of holding a dedicated class about Agile SW development in the Computer Science degree course at University of Salerno.
What a great time interacting with clever guys eager to learn and experiment new things!
It was long ago we started discussing the opportunity of sharing some of our learning and experience with our local university where we hire most of our people from, since we found essential to instill a culture of agility into the new generation of students, who, after more than 10 years from signing the Agile Manifesto, are still taught mostly traditional SW development techniques and lack an accurate introduction into state-of-the-art methods and practices.
Consider that almost no student we met knew even the name “Scrum” before we taught them.
So last year we managed to convince an interested professor to give us 10% of his 60-hours SW engineering class to talk about Scrum and SW craftsmanship.
The response from the students was so enthusiastic, that rumors flew very fast around and another illuminated professor came with the idea of organizing a 20-hours class about Agile, containing all subjects we considered important.
It was the chance we were waiting for.
So we designed our class, which we named “Agile methods and practices”.
Yes, because that’s what we think an Agile team needs to be successful: using an effective method like Scrum to organize the work, but at the same time master effective practices to get the job done.
That’s why we decided to present Scrum in the first half of the course (where we could leverage on our 400+ class hours experience in teaching Scrum to Teams and Product Owners) as a simple, effective and educational framework to help a group of people become a high-performing agile team.
However, being very conscious that Scrum is not enough to sustain an effective agile SW development, we wanted to spend at least the same amount of time to explore together “The Land that Scrum forgot”.
But how to do that?
But how to do that?
While teaching and coaching our Scrum teams on SW craftsmanship, we realized how difficult is for people used to develop SW with a traditional approach even imagine how it can be possible to have an emerging architecture, or doing the analysis by writing Acceptance Tests or writing iteratively Unit Tests before even thinking at the code and continuously re-factor the code.
Therefore we needed to create a consistent story!
Our approach was then to zoom inside a Sprint and practically show how a selection of agile methods and practices could be used effectively to transform a User Story in a potentially shippable product increment.
Yes, because this is the real challenge for a Scrum team: get a bunch of User Stories done without doing a mini-waterfall inside the Sprint.
The framework we proposed during the lectures was the following:
- Use Behaviour Driven Development to collaboratively write Acceptance Test scenarios out of a User Story
- Use Test Driven Development and Pair Programming to write the minimum amount of code to make a single Acceptance Test passed
- Use Continuous Integration to make sure you always have a potentially shippable product increment
- Repeat the approach iteratively until all Acceptance Tests are passed and then all User Stories are done
We did this by assigning them a real SW project to develop in teams, partly during the lectures and partly as homework.
Obviously our ambition could not be to make them learn these practices in few hours, but mainly to create awareness and stimulate curiosity about alternative ways of thinking about SW development than what they are taught everyday. However what some of them achieved, regardless the small amount of time available was really incredible, as one can smell from this link.
Given the feedback we got from the students, the class was appreciated, also because of the interactive teaching techniques we used to get the content through.