ScrumMaster and ZenMaster: The joke of certification

Many people object to ScrumMaster certifications:

  1. It's a money making machine
  2. Scrum Masters do not learn anything during classes
  3. The certification is nothing worth - because nothing is certified

I have been a Certified ScrumMaster (CSM) and a Scrum practioner for some years. People who object to the certification do see it from the wrong angle. You need to understand Zen to understand the goodness in CSMs.

Creative Commons License photo credit: darkpatator

Certification is a Zen joke, because the role of a ScrumMaster cannot be certified. It's not about knowing some technical questions. What should a trainer certify in such a class? That you can lead an agile Scrum team as a ScrumMaster? No one can certify the fact that you're a leader, catalyst and enabler. You either are or you aren't. Zen masters (ha, another master without a master!) would laugh at the fun in the ScrumMaster certification. They laugh about the idea of certifying enlightenment.

Scrum without ScrumMasters

As another parallel, both in Scrum and in Zen, masters are only enablers. They are not needed after the act of enabling Zen/Scrum. My Scrum trainer told me, the goal of a ScrumMaster is to make himself obsolete. There is a Zen koan which goes like this:

If you meet the Buddha, kill him.
— Linji

If you see a ScrumMaster, kill him. Zen tells you:

If you are thinking about Buddha, this is thinking and delusion, not awakening. One must destroy preconceptions of the Buddha. Zen master Shunryu Suzuki wrote in Zen Mind, Beginner's Mind during an introduction to Zazen, "Kill the Buddha if the Buddha exists somewhere else. Kill the Buddha, because you should resume your own Buddha nature."

If you think the ScrumMaster is Scrum, you're delusioning yourself. In Scrum the product owner and the scrum team can, and should from my view, act by themselves, without the need of a ScrumMaster. The ScrumMaster helps them achieve their Scrum. Helps them overcoming initial obstacles in their productivity.

Kick your ScrumMaster
If the ScrumMaster is not good enough for them, certification and coaching inside the company hasn't helped, the Scrum team has always the right to kick their SM if he isn't good enough for them. And they should do so. If in Zen a master isn't good, pupils will just leave him. This might lead to problems within the organization, especially if the ScrumMaster is their boss, but that should be the problem of the organization, not a team problem.

Practitioner certification

There are many more certifications from the Scrum alliance. If you dig deeper, the real fun part is that CSM doesn't mean anything, practitioner means much more:

The practitioner level of certification (CSP) is only offered to those CSMs who have hands-on experience using Scrum. Applicants must complete an extensive questionnaire with probing questions that focus on applicants’ real-world experience using Scrum on software development projects. Their application is reviewed for answers demonstrating competence and comprehension of principles that can only result from hands-on work. The applicant may be questioned to determine eligibility. To maintain CSP status, you must submit a new application every two years.

Is the certification any use?

Yes. The Certified Scrum Master training has several merits:

  1. Calling the Scrum training "Certified" guaranties the quality of the trainer
  2. It motivates the Scrum master to think in Scrum
  3. If managers take part, it helps the organisation adopt a "we can do it" view about Scrum
  4. Certification (CSM) seems to be one of the main reasons for Scrum success in the enterprise. The certification makes Scrum compatible for managment.

The view about acceptance is shared by Peter Stevens:

It is also about branding, and has been quite successful. The acceptance of the CSM program is high (especially from corporate customers, and this is where the money is). I believe the CSM program is an important reason why Scrum is better accepted than say, XP, in corporate management circles.

Scrum is successful. I've seen it help development departments gain productivity. If you do not scrum yet, go for it.

The future: web development without web frameworks – my slides from the first Berlin Java conference

Together with one of the senior developers on my team I gave a speech at the the first Berlin Java conference called Berlin.JAR. The topic was about how to develop applications for the web without a (traditional serverside) web framework. There is a wave towards rich AJAX applications with GUI logic in Javascript. Two forays are SOFEA and SOUI. The speech covered examples of how to design web applications without a web framework with rendering in Javascript and a client side message bus, using REST, Jersey, OpenAJAX, PURE JS and jQuery. My slides in an English version can be found on SlideShare or here.

The really nice thing is that backends can be written - independently - with Ruby, Python, Javascript, Java, Clojure, Scala, Erlang, OCaml or any other language. As integration doesn't happen on the server but in the browser (late and lazy integration), it's faster (asynchronous) and easier than on a server.

Thanks for looking.

JsonBuilder for Scala, REST and Jersey

How to generate Json for REST? If you're suspicious of automatic generation like me?* I've created a markup builder which can be used with Json and made a look into the future in my post "The best Markup Builder I could build in Java":

"Closures in Java 7 will make it much easier to write a MarkupBuilder. The Action and Loop inner classes will go away and the code will be more Groovy like."

* For a discussion on why you might not want to use JAXB and XStream see the comments on "REST: Lean JSON and XML from the same code"

Let's have a look at this quote again. I didn't use Groovy but with some interest in Scala - because it might be more maintainable than Java after 5-years project life time as it is more concise but not riddled with the Ruby-problems or unreadable for most as Haskell is - I looked at my JsonBuilder code and tried it with Scala.

I went back to the "Experiments to nicely generation JSON" post and did adapt it to Scala.

class HelloWorldResource {
  def hello() = "Hello"

  def helloWorld = $( 
      $("id", 128),
      $("name", "stephan"),
      $("roles", => $("name",,
      $("adress", $(
        $("street", "mine!"),
        $("city", "Berlin")

The generating code looks the same as in Java, with the possibility to include functions for generating nodes. My Java code did need anonymous inner classes to achieve the same - with more noise and less power. The methods are shorter and the focus lies more on generating the JSON data, not the method boilerplate code. Next will be WebBeans or Guice integration.

Ive struggled with some Scala constructs, the JsonAdapter which implements MessageBodyWriter was a little hard to write, especially:

   def writeTo(node:Node, aClass:java.lang.Class[_], 
                outputStream:OutputStream):Unit = {
    val writer = new OutputStreamWriter(outputStream);
    writeTo(node, writer)


  def isWriteable(dataType:java.lang.Class[_], typ:Type, annotations:Array[Annotation]) = {

But everything works now and I can move on to adapt and learn how to do it better in Scala.

The migration wasn't that hard, some problems exists and my Scala code looks more like Java than Scala, but it's a beginning. One of my fears is to translate between Seqs, Lists, Arrays and Java Lists and Iterators all the time when interfacing with Java libraries. Not sure yet how to fix that, perhaps with some wrappers. Scalaz might help too. We'll see in my future adventures into Scala.

Thanks for listening.

Unscientific Jetty versus Glassfish for REST

This post was too unscientific and was updated. Jetty is an excellent container and the container of choice whenever I do something with servlets. Ever since we’ve developed SnipSnap some years ago I love Jetty. Glassfish has some very promising features like the admin console and I´m eager to try Glassfish in a project sometimes in the future.

Reading about another story of Rails performance, I grabbed JMeter to benchmark one of my current projects. Not so much as a comparison for Ruby - which managed 320 requests per second - but more as a comparison of Jetty and Glassfish.

The application is a small REST server which reads data from a JDBM storage, transforms it with my own framework to Json and delivers the result with Jersey.

Both servers were started with their default configuration through their maven plugins (wonderful easy to use mvn glassfish:run). Unscientific as it may be, the numbers are:

  • around 1000 requests/sec for both containers

Both with 200 threads and 50 requests per thread. Both numbers are great for my MacBookPro and good enough for me. They also are so close to each other so they are not a deciding factor for either Glassfish or Jetty. At the risk of comparing apples to oranges I have no fear of deploying this to a production system and scaling cheap (and even better with E-Tag caching), keeping in mind the requests per second with 25 servers in the Rails example.

Thanks for listening.

Update:: Another Rails application which thinks it did scale - at least with Merb, to 650k page views per day, well that's "650K hits per day is 'only' around 8 per second (assumed a 20 hour day to spike it a little). This doesnt actual seem all that much?".

The JMeter speed and 1000req/sec (for an admittantly simple REST GET) results in ... 86.4M requests per day. Uh. On my MacBookPro.