Software product management is easily the least well understood yet most important business function in software companies. I have been teaching Software Product Management by Case for about ten years now, and it is time I change a gear or two. Hence, I’m asking whether anyone is interested in helping me teach this course, whether in small or large capacity. For details, please see this slide deck:
My research and teaching group just celebrated its tenth anniversary, and I wanted to take some time to reflect on our teaching: What worked and what didn’t.
When I started as a university professor ten years ago, I drew on my experience as a student, as a teacher, as a practitioner, and as an entrepreneur, to define the basic principles of how I wanted to teach:
- Theory and practice should be joined at the hip; there should only be minimal delay, if any, between hearing some concept and applying it in practice
- Learning requires repetition and practice, so the theory and practice of something to learn needs to be drawn out over several iterations to become effective
- Learning is a marathon, not a sprint; therefore, learning and using the stick (grading) to direct learning should be continuous and not a fire-and-forget exercise
- Feedback needs to be immediate and connected to a student’s actual doing, and not come at the end of a semester or later
- Learning is holistic; while some concepts can be isolated, more often than not, concepts interact and require a realistic setting to be learned
Software product management by case is a college-level course that I created for teaching product management to computer science students. Using the case method, it helps students understand complex real-life situations in product management as well as the strategies and methods used to deal with them.
Some cases are not about product management, though. An example is our case about stock options. Using the IPO situation of one of the dotcom bubble darlings, Caldera Systems Inc, the case helps students understand employee incentive systems and stock options. We were fortunate enough this time to have Stefan Probst in class, who ran Caldera’s German subsidiary.
Stefan answered students’ questions after we finished the case analysis and shared war stories of the dotcom bubble days. Thank you, Stefan, for teaching us!
tl;dr The software development contexts that I deal most with these days are open source projects and fast-moving startups; both don’t seem to have much use for what is traditionally taught in software architectures courses.
Let me start by saying that I love a good software architecture as well as software architecture in general. My dissertation was on better modeling object-oriented frameworks and I have played the architect role for most of my engineering days. I even started a traditional software architecture course at my university. However, I got bored quickly and couldn’t connect it to the practice I dealt with, so I passed the course on to a colleague who is now teaching it. I do teach, however, the associated software architecture project, in which student teams perform some analysis and provide recommendations on a real-world architecture provided by an industry partner.
Teaching Scrum at University is challenging. Students are typically at the beginning of their career and don’t understand the challenges of communication and coordination in software engineering well. In a prior post on Why I Still Teach Scrum I had made a cryptic remark to that end and through various channels was asked to clarify the remark.
Scrum is a framework that needs tailoring for the specific situation at hand. The specific challenges of teaching Scrum at a University are, in no particular order, and most certainly incomplete:
- Comparatively little practical experience of students
- Widely differing capabilities as the gap between students can be large
- Transient teams as Scrum projects typically last only a semester
- Zero-Sum-Thinking by some students as to teamwork and grade
Scrum is an agile method (framework) that when instantiated can be rather ornate. Most developers, when I talk to them, tell me that when given a choice they would not be doing Scrum. While Scrum may have felt much lighter than the competition back in the nineties, today it weighs in as rather heavy.
Given this, I wanted to reflect on why I still teach Scrum (and have a blog post to point any of my students to).
In PROD, my course on software product management, students can choose to develop a business plan for a software product. Not all of my students seem to take this as serious as I wished. Here is the opening sentence of the exec summary from one of the teams:
With a total loss of 388,987.50 Euros in the period of 2017 to 2019, we will increase profit by 2,123,121 Euros and the customer base by 1392% […] Break even will be reached by mid 2018.
Reminds me off the bubble days: “We will make 80 cents for one dollar spent and will be profitable in no time!”
I’ll be keynoting the European Conference on Software Engineering Education on Nov 28, 2014, at 11:00 Uhr, at Seeon Monastery, Germany. Here is the abstract. See you at the conference!
Over the last few years, we have shifted most of our courses from traditional upfront lecturing to project-based learning. Each course consists of multiple projects with three main stakeholders: students, teachers, and industry. Using AMOS, our “agile methods and open source” software engineering course as the example, we review our course concept and discuss our experiences. We take the perspectives of the three stakeholders in turn: Achieving learning goals and performing meaningful work (students), fulfilling both an educational and an economic mission (university), and receiving a return on time and monetary investment (industry). The perhaps surprising result is that these three perspectives can work together well and make reaching each stakeholder’s goal easier.
We recently discussed our approach on my research group’s website as the “Lehrkonzept der Praktischen Softwaretechnik an der FAU” (in German).