I have heard several talks and attended several presentations both comparing Scrum and Kanban and explaining how they can be used together. I came across this article, which talks about this article (I list both because the commenting article brings up good points, too). So why am I adding yet another level of indirection to this chain? Because an awful lot of people understand past the surface and the buzzwords of the various flavors of Agile/Lean, and that leads to confusion, unmet expectations, and failed projects. The most important point of these articles is that Scrum and Kanban are not interchangeable techniques. They differ greatly in scope and goal. That’s why they bring up the metaphor of choosing between a knife and fork.
I fell upon this article on the Methods & Tools website, a free software development magazine on software development and software engineering. The author is Anna Forss. She lives in Sweden, and her English is not perfect, but the article’s content is so strong, it’s worth the read. I recommend this article to anyone who wants to get a feel for what Scrum is, especially if you’re not a Software person.
The article starts out with an overview of the heart of Scrum, and how it doesn’t tell you how to develop your software per se. It tells you how to organize and communicate, but it doesn’t cover anything like unit testing or pair programming. You can combine Scrum with other practices effectively.
The main part of the article is about the roles people play in Scrum, in particular the Product Owner and the Scrum Master. Anna is a Product Owner (she doesn’t do any Software Engineering herself), and this part of the article implores the non-Software people in Scrum-using companies to take the time to learn it better, so they can be more effective in interfacing with the developers. Since I travel mostly with other Software Engineers, I hadn’t really heard about Scrum from the other side very much, and she makes a strong case for selecting the people to fill these two roles very carefully. A good Scrum team can get by with an OK Scrum Master, but a Product Owner that doesn’t do their job right will surely kill a project. She also addresses why the two roles shouldn’t be filled by the same people.
Anna Forss has a blog here (I almost want to publish some articles as RDF Triples). Her own blog has some great posts, like this one on The Business Value Of Boring Stuff and What Can We Learn From Coffee?. She’s also the author of Confessions of a Serial Product Owner. My only complaint is that her blog is on Windows Live, and I’ll be damned if I’m going to get a Windows Live ID so I can post comments on her blog or subscribe to it.
Scrum has been a very widely adopted Agile process, used for managing such complex work as systems development and development of product releases. When waterfall is no longer in place, however, a lot of long standing habits and dysfunctions have come to light. This is particularly true with Scrum, because transparency is emphasized in Scrum projects.
Some of the dysfunctions include poor quality product and completely inadequate development practices and infrastructure. These arose because the effects of them couldn’t be seen very clearly in a waterfall project. In a Scrum project, the impact of poor quality caused by inadequate practices and tooling are seen in every Sprint.