What’s Wrong in Software Product Line Engineering? Insufficient Collaboration between Product and Platform Unit

As previously posted, we analyzed current problems in product line engineering. One case study was a healthcare software product line, one was a business software product line, and one was a telco carrier software product line. All developers in their respective product line were homogeneous in time and culture (one main location, one social culture), that is, we had no problems of globally distributed software development. This both made the analyses easier but also limits the generalizability of our conclusions.

We presented our analysis using cause-and-effect chain diagrams. The following figures shows an excerpt of these diagrams.

Continue reading “What’s Wrong in Software Product Line Engineering? Insufficient Collaboration between Product and Platform Unit”

What’s Wrong in Software Product Line Engineering? Lack of Resources in the Platform Organizational Unit

A few years ago we analysed several highly successful software product lines. You can find the details in our corresponding publication. We had been brought in, because the business owners of each product line felt that something was amiss and that productivity could still be improved. In this short blog post series I’ll discuss the problems we found and what to do about it.

Continue reading “What’s Wrong in Software Product Line Engineering? Lack of Resources in the Platform Organizational Unit”

Commercial Open Source in the Cloud

The brouhaha around Redis Labs taking some enterprise modules of its popular open source in-memory database Redis closed source has somewhat calmed down. However, I didn’t see any discussion of what I thought was the most interesting conclusion of the affair: A core strategy of commercial open source,

the dual-licensing of the software under an aggressive copyleft and a commercial license may not work when cloud providers are involved.

To recap: Redis Labs develops and provides to the market the open source in-memory database Redis. It follows the commercial open source playbook: “Free-loading” users can use the software for free under the AGPLv3 license. Paying customers receive a commercial license. Those with a commercial license do not have to open source their application code, while non-paying users may have to. These are the effects of the AGPLv3 for the free version. It does not apply to in-house solutions, even if hosted in the cloud, but it does apply to software vendors that provide on-premise or hosted solutions to third parties, that is, their customers. To avoid having to open source, software vendors purchase the commercial license and Redis Labs makes some money.

Continue reading “Commercial Open Source in the Cloud”

If GitHub Was Like Berlin…

Much open source research assumes that all open source projects are alike and that if you take enough of them, you can claim generalizability for your conclusions. GitHub is the main source of such mischief, because of its size and availability.

If GitHub was like Berlin, and projects on GitHub were like the people of Berlin, then treating all projects the same is like saying that a person from Mitte is like a person from Kreuzberg is like a person from Spandau.

Continue reading “If GitHub Was Like Berlin…”

Clarification of “Why I Still Teach Scrum”

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

Continue reading “Clarification of “Why I Still Teach Scrum””

There is no Product Owner

One of the most difficult aspects of Scrum is the role of the product owner. Most software vendors have a product management function, typically split into strategic and technical product management. Technical product management is usually equated with Scrum’s product owner role, that is, the guy or gal who writes business-value-oriented user stories and epics, grooms the product backlog, and then some. This is separate from breaking down business-oriented features into technical tasks, which is left to the engineering team.

The problem: A person who can do this well is hard to find. It is easy, though, to find someone who believes they can be a good product owner. In practice, most successful software vendors I have seen have a business-oriented strategic product manager for a given product or major component, and have a senior engineer play the product owner role, reaching all the way into product development, that is, not only writing users stories but also breaking them down into tasks.

I’m a strong believer in product management. It is the most critical function in product development. It took me many years to accept that good Scrum product owners cannot be groomed from MBA or other business-oriented degree programs. Almost always will you need someone with a technical background to fill that role or it will go off the rails. However, there are really few people who’d like to take on that job; they’d rather be programming. Therefore, you’ll have to ask a senior engineer or other engineering leader to collaborate with the strategic product manager and turn the roadmap into features that can go into a product backlog.

So, as I said there rarely is a (stand-alone) Scrum product owner; usually it is a senior engineer adding to their busy schedule to make things work out.

Agile Feature Teams vs. Inner Source

Agile methods reacquainted developers with the idea of working from business value rather than focusing on technical concerns only. Agile methods are therefore often equated with feature-driven development, in which work is driven by features prioritized by business value irrespective of technical consequences. This thinking can create code silos and wreak havoc on software architecture and component quality. Developer complaints are legion, in particular for never getting the time to fix things or do them right in the first place.

Continue reading “Agile Feature Teams vs. Inner Source”

Why I Still Teach Scrum

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

Continue reading “Why I Still Teach Scrum”