Tag: scrum.org

Posted on by — 10 Comments

Why It Took Time (to become what I didn’t know I wanted to be)

The terrorism of an alcoholic father left me with serious damages and memories of a loveless youth. Nevertheless I graduated as Industrial Engineer in electronics in 1992, age 22. An opportunistic choice of study as philosophy or literature didn’t offer the same job certainty. Purpose?

Time for a little retrospective exercise. What has happened in the 20 years since my graduation? What has been most influential in becoming who I am today? And why did it take that time?

The formative years

I was deeply disappointed when entering the labor market as my grade created the expectation of thorough technical insights while I had hoped for some staff position, and the possibility to work with teams.

My first job was software engineering on VAX but I remember most the great times I spent in the great country of Ireland. After a little project on OS/2 I moved to a small company in 1993 to do assembler programming on Micro-PIC controllers. My 6 months trial period wasn’t too convincing but a one month prolongation did show some success in planning and purchasing, combined with Borland C++ and Paradox programming.

Blind enthusiasm and overwork burned me out so I left in 1996 to take over a bookshop of a large chain on a franchising base. A client of our shop pointed me towards Nietzsche and his ‘Beyond Good and Evil’ (and later on his other works) was an incredible eye opener. Since then I kept saying that 90% of who I am, I am due to my wife and 9% due to Nietzsche. Nietzsche revealed the bare truth to much of my struggles with life to that date. Although my wife and I had the time of our lives being all around books, and we moved to a bigger shop twice, on the last day of 1998 we had to decide to quit. The reason was the imbalance of income, social life and personal development; and being on the verge of debts.

In 1999 I started as business developer for the first Belgian e-commerce site for books and CDs, where I soon grew into a senior management position. By the end of an exciting but burning period I remember me creating a mega (no, wait, giga) analysis for a complete new back office (from IT to logistics), which was my domain to lead. It only took me 3 hours to get a team through it. Once. I don’t know whether it was that analysis or the complete renewal of our server park, but just after I resigned in 2001, I was offered the position of IT director at the company. Although I did co-write a post-crisis survival business plan for the company, I still decided to leave. I felt too young, too inexperienced and -above all- my views on the people aspect were quite different from our investors and other leading managers. I rightfully left, is my opinion still. Later that year, our first son was born.

The Years of Dedication

In 2001 I started working for a large local (Belgian) consulting company.

For my first project I did a complete functional analysis, took the lead in contracting and other negotiations and continued as ‘project manager’. Management advised me not show the estimates to the team. But I did, and it didn’t prevent the project from ending up break-even where all other fixed prices ended in major losses. But I specifically remember helping a team member through a difficult divorce situation. Without minding the actuals.

In 2003 our second son was born. He turned out to have Down Syndrome. Professionally I got called to urgently lead a new project that seemed unfeasible despite the fancy MS Project promise. It took 15 minutes for 2 software architects to convince me about eXtreme Programming. It just had all elements fixed in the method that I had -to a certain extent- tried to do in my first project: communication, iterations, feedback. In December 2003 I presented this project as the first major production XP implementation in Belgium at Javapolis.

When scaling up with the next phase of the project we added Scrum in 2004. I went well-prepared, i.e. having read his 2 books at that time, to a CSM class by Ken Schwaber. And we replaced our organizational XP practices with Scrum practices and names, but we kept doing the core engineering practices (pair programming, TDD, continuous integration, automated testing).

By the end of 2006 we had successfully delivered 2 more phases of our early Agile project, and applied Scrum + eXtreme Programming in 2 additional large website applications, incorporating extensive front-ends, back-ends, integrations and interfaces. Those projects learned me that inclusion of incremental development of even major UX-components is feasible, and even to be preferred.

Due to lack of respect for our results and for the people I decided to leave in 2007. And to date I’m still struck by the observation of an esteemed colleague and team member that I had never consciously made myself, i.e. that he loved the way I tried to turn a project into a total, 360° experience of joy, fun, energy and… results. Never satisfied with less.

Richard Dawkins deepened my Nietzsche experience by adding a genetic and memetic dimension to it. By the end of the year I started at another consulting company, led and blinded by promises of a management position. Around that time our oldest son, age 6, was diagnosed with Duchenne Muscular Dystrophy. Having read Richard Dawkins helped in surviving and dealing with the genetic flaws of our 2 children.

The empty management promises finally covered 2 years of my life in stress and agony. I fought, battled and barely survived, before returning to my Agile roots. I realized that I had never cared about any ‘CS*’ certifications or whatever career, that my satisfaction had been in working with teams and clients, joyful projects, and that I still didn’t care about careering. Therefore I was attracted by the community orientation of Ken Schwaber’s new platform, Scrum.org and followed and joined it from the early days in 2009.

2010 did not only see me giving consultancy a last chance at my current employer, but after 2+ years of medical uncertainty and wandering our daughter was born. No genetic problems, not even carrier of DMD. My first professional experience wasn’t too comforting, but I applied my iterative-incremental approach and turned my first project, once more, and once more against all odds, into a 360° success. In the mean time I evolved with Scrum.org and did the Professional Scrum Master assessments (level I and II), and decided to firmly proceed on that path. I applied for Professional Scrum Trainer for which I went to a PSM class by Ken by the end of 2010 in Zürich.

Booming Business

And then, suddenly, there was 2011. Dutch colleagues found me. I developed an internal Scrum training, which was highly appreciated and became very successful. It opened important gates at clients, caused some amazing breakthroughs and I mutated to another division. I followed the early Professional Scrum Product Owner program and soon became Professional Scrum Trainer in PSM and PSPO.

I had a boost in understanding and living Agility, not in the least through the mentoring and lessons by Ken. My perspective quickly broadened. Authors like Daniel Pink (“Drive”) and Nassim Taleb (“The Black Swan”) augmented my general world views, and greatly supported my belief to use people and empiricism to cope with the complexity of our world. I am now the global expert on Scrum at my company (120.000 people worldwide). And the end is not nearly in sight. Scrum has become a substantial part of what we do and offer. We train our consultants and our clients, we coach and guide them, we promote Enterprise Agility and we inject more and more agility into our own organization.

Soon I will be talking at the Scrum Day Europe event that Scrum.org initiated and that we co-organize. I will introduce how I perceive the Emergence of the Customer-Oriented Enterprise. Previous ‘confessions’ gave some insights in what might have influenced how I developed my views. Who knows what will happen next to change how I see things?

Not Future

Some things take time. Beauty. Growing flowers. Becoming what you didn’t know you wanted to be. Unlearning. Mastery. Dedication and determination.

I am still without much formal title or position. I regularly struggle with the gigantic, monstrous machines that corporations tend to be. I regularly want to flee back to the underground when balancing my personal ethics against my desire for impact. Overall however, I manage and it works out… without power games. I am epigenetically (the seeds sown in my youth) unable to play power games, but I’ve learned to use that in my advantage.

In 2012 I am even making enormous progress on my scales of valuation. In the past I usually was merely tolerated, in the best case appreciated.  Here I am now, not just being motivated, but even able to innovate.

Note

I started writing this blog note to give people insight in what it sometimes takes, at least time, to learn and evolve. I was long in doubt whether to continue this text when I started reading Lyssa Adkins’ book Coaching Agile Teams. Having read the first chapter I decided to go for it. Because my message reflects how I became to ‘be’, not only what I ‘do’. Painful sometimes, but honest. Hoping it might help or inspire others. Hoping it helps people understand that it takes time. The path and the patience pay off. I can now go back to Lyssa’s book again and finish reading it.

Posted on by — Leave a comment

The importance of Done in Scrum

In the last Scrum Guide (July 2011) the definition of Done was given considerably more attention. Rightfully, as “Done” is crucial in Scrum.

The Importance Of Done

The definition of Done is essential to fully understand the Increment that is being inspected at the Sprint Review with the stakeholders. The definition of Done implements the expectation of an Increment to be ‘releasable‘, so ideally it is comprised of all activities, tasks, qualities and work that allow releasing an Increment in production. The addition ‘potentially‘ to releasable refers to the Product Owner’s accountability to decide over the actual release of an Increment; a decision that will likely be based upon business cohesion and functional usefulness. But the Product Owner’s shipping decision should not be constrained by ‘development’ work.

The definition of Done should be clear and concise for the Scrum Team as it will determine how much work a Development Team can reasonably take in into a Sprint during the Sprint Planning meeting.

The empiricism of Scrum only functions well upon transparency. That includes the definition of Done. Transparency means not only visible, but also understandable. Besides being available, the content of the definition of Done should be clear by just reading it.

A New Scrum Artefact?

Should we make the Definition of Done an official Scrum artefact?

It would seem like adapting Scrum to reality, a mere formalization of an existing practice; because it is extremely important to put quality even more at the heart of what we do; because we want to clear out that little grey zone in the base Scrum framework allowing some people to doubt the formal need of a definition of Done. With regards to the latter, it would provide additional guidance for people and organizations to improve, and investigate the next steps on the cobblestone path to Agility, although probably not the guarantee hoped for by making it a mandatory artefact.

All existing Scrum artefacts support the ‘inspect & adapt‘ cycles of Scrum; they provide accurate, up to date and transparent information to be inspected and adapted at the rhythm of the Scrum events (or sooner). In that sense, Done is already an artefact; it is in the Increment, making the state of the Increment transparent.

I suggest to formally include inspection of the Definition of Done at the Sprint Review, along the inspection of the working Increment, which it is a characteristic of. This pair-wise inspection serves to get feedback and input from the stakeholders that goes beyond mere functionality and business requirements. It will invoke a collaborative conversation over quality, and requirements with regards to the quality of working software in the organization.

The Sprint Review is also the time to inspect the current state of Product Backlog, i.e. what is now Done, what was left undone in this Sprint, what was additionally turned Done. From this current state, including the latest Velocity measurement, the actual product progress is available to the stakeholders.

I suggest to lay ownership over the definition of Done with the Development Team. A definition of Done can’t be forced upon a Development Team. Neither can it be cut short by forces outside of the Development Team. The Development Team will obviously include functional quality expectations from the Product Owner. The Development Team will obviously include general, organizational expectations and compliance (e.g. from the development or engineering organization). But it’s up to the Development Team to process it in the definition of Done. Decisions over the definition of Done will depend on the presence of skills, authorizations and availability of external systems, services and interfaces. Probably a Development Team would include stubs and simulators for non-available systems, add this to their definition of Done and make the impact of these dependencies clear to the Product Owner for ordering the Product Backlog. The effect on the planning horizon will no longer only be clear to the stakeholders by inspection of the Product Backlog at the Sprint Review, but also via explicit inspection of the definition of Done accompanying the working Increment.

The inspection of the working Increment and the definition of Done at the Sprint Review, and the related collaboration of the Scrum Team with the stakeholders, will provide the Development Team with important information to sustain, evolve and grow the definition of Done. They will probably have a deeper conversation over it at the Sprint Retrospective. The self-organizing drive of the Development Team will include all that’s actually possible, dig deeper, taking into account the feedback from the stakeholders, and evolve it as part of their continuous improvement of quality.

This ownership is comparable to the Product Backlog ownership. The Product Owner has accountability over it. But it won’t withhold the Product Owner from taking into account the technical and development input from the team. It won’t withhold the Product Owner from taking into account dependencies, non-functionals and organizational expectations. And after all, the frequent inspection of a working Increment provides information on reality to all involved so they can incorporate that in their work via their accountability.

A Desirable Side-effect

Although the goal is not to promote the Definition of Done to a Scrum artefact (as shown that is not needed), I do see an optional side-effect in explicitly inspecting it at the Sprint Review: additional transparency to the overall agile adoption.

Obviously the definition of Done will not always immediately, from day 1 of the adoption of Scrum, hold every possible task, activity or requirement to render every Increment completely production-ready. There will be a gradual evolution in applying Scrum. This is good as it helps all players continuously exploit the possible to a maximum extent.

Promoting inspection of the definition of Done with the stakeholders will help identify improvement areas in capturing enterprise agility. The finding of what is/is not included provides an indication on involvement of the broader organization in agile product development, even of organizational impediments. And stakeholders, in consultation with Product Owner and Scrum Master, might want to act on these from a management change perspective.

In a transformational period, including the definition of Done as an explicit artefact in the Scrum framework will help people and organizations in the software industry to… improve from better and more realistic insights.

Posted on by — 1 Comment

Personal Professional Scrum

Precaution: the author (me) is lately sharing a load of personal, retrospective findings with the world (you). Must be that he’s leaving some troubles and worries behind him. Or maybe it’s just the pills he’s taking?

It wasn’t until I started doing projects upon eXtreme Programming (2003) and Scrum (2004) that I finally found my way in IT, and started feeling at ease at a personal-slash-professional level. It then still took me several years (>2011) to find a professional homebase (some call it an employer) where I could really ‘go’ for my Agile and Scrum ways.

In the early years I never cared about profile or promotion; just me, expertise & the teams. But on the cross-point of deciding yes or no to stay in IT consultancy, I decided to give it one more chance. But it would be a ‘make or break’ and it had to be Agile and Scrum. I resurrected the knowledge and experience hidden in my brain and started publishing about it again. I finally went to Capgemini (March 2010), attracted by the fact that they had co-founded the Agile Consortium Belgium.

This was around the time that saw the emergence of Scrum.org by Ken Schwaber. I had my CSM by Ken back in 2004 but that was it. Never even considered CSP, CSC, CST or any other CS*. My reluctance for profile and promotion, you know. I liked the feel and the why of Scrum.org and engaged early. Full of doubts, but I demonstrated a good understanding as Professional Scrum Master, level I and level II. Confidence grew, I applied for PSM trainer, went to a PSM course by Ken (December 2010) and qualified as trainer.

Happily invited at an early class of the new Professional Scrum Product Owner program (April 2011), I fully subscribed the program’s goal of reaching out to Business people and helping Agile Product Management emerge. I demonstrated my understanding and my training qualification was extended with PSPO.

After a little migration within Capgemini I am now in the greatest position ever of working day and night in promoting, maintaining, supporting, coaching, training and facilitating Scrum; internally as well as at customers, locally (Belgium and Netherlands) and globally. And the Capgemini Academy is rolling out a training offering for private and for external audiences that combines:

  • Our Capgemini trainings: Scrum Kickstart, Scrum for Product People and Scrum for Managers;
  • The official Scrum.org trainings PSM and PSPO.

Our strategy connects to the vision of Scrum.org in presenting Scrum as a tool for Business Agility, not as an end in itself. As from Capgemini I sincerely hope to have impact but from a positive, open and adaptive attitude. Not grumpy or bitter or aggressive. Knowing that the path to Agility will remain a cobblestone path and there will be ups and downs. Keep an eye on the overall progress trend, a burnup chart of Agile values and Agility. Make the world a better place (to work in).

Posted on by — Leave a comment

Why I loved going to the PSM Course

Early December 2010 I went to a Professional Scrum Master (II) course in Zürich, taught by Ken Schwaber and facilitated by Zühlke Engineering. Already being a PSM II, I went mostly to see Ken and to look to improve my own teaching skills. And it was a very enjoyable event!

Ken and the ScrumAlliance parted in 2009 leading to Ken establishing Scrum.org. As an outsider I don’t care about the circumstances or the rumors surrounding this. I’m only concerned with the profession of Scrum, that I have now been practicing for 7 years and for which I truly believe that Agile is finally crossing the chasm in the lowlands of Belgium and The Netherlands (and other parts of our old continent of Europe).

And I can only conclude that Ken has learned his lessons by:

  • Separating course attendance from assessment/certification;
  • Incorporating community feedback;
  • Creating a development course and for Scrum Teams in general;
  • Setting up a Product Owner program with a separate assessment;
  • Upgrading the PSM course material.

For the latter I can testify that a number of topics were already treated in my CSM by Ken in 2004, but new stuff and ideas have been included far better than in recent CSM course material that I compared it to.

What I strongly like in Ken’s teaching is his holistic perspective on Scrum, like the spirit of the Scrum Guide that he co-wrote with Jeff Sutherland. His courses go well beyond the formal mechanics of Scrum. It’s much more about why Scrum works, its psychology, the positive thinking, the social aspects. And the empirical foundation of Scrum to help us not even trying to predict the unpredictable. And beyond the theory, luckily, Ken has tons of stories and cases to share with the training participants.

This PSM course has certainly inspired me in my teaching of the Scrum Trainings that I launched at Capgemini. At a considerable scale of internal participants and geographical spread. Hoping that I can open these trainings to external audiences, and maybe even as PSM Trainer…

Posted on by — Leave a comment

Scrum – Beyond the ceremony of certifying

Why would you want to certify in anything Agile, and Scrum especially?

Well… you don’t. The right attitude will make you:

  1. want to learn about Scrum from an expert as a head-start for practicing it. Truly taste it by using the tool to get more Agile.
  2. want to assess your knowledge and experience.

Exactly the needs that Scrum.org is addressing. To think beyond courses. Knowledge, understanding ànd experience over paper certification, which I certainly value more:

  1. For learning purposes there is the Professional Scrum Master course, i.e. a retake of Ken’s former CSM.
  2. But there is a unique set of online assessments:
  • With the help of the communities an open assessment was created. I participated in it at the time it was still called Scrum I. It’s free of charge and you can use it as a quick check on your knowledge.
  • The level I assessment checks the fundamental Scrum knowledge (the cost of 100 $ is also included in the PSM course fee). A score of 85% is required!
  • The level II assessment requires 85% as well, which is not achievable without even more demonstrable knowledge, having applied Scrum and understanding the underlying principles. As I wrote in my blog note “Unsatisfied? Uncertified? Unvalued?“.

And, finally, Ken is assisting the development communities with the Professional Scrum Developer program, holding a course and assessments in a .Net and a Java version.

The knowledge of Scrum is verified against the Scrum Guide from co-founders Jeff Sutherland and Ken Schwaber. Capture their insights!

An highly unserved and underrated audience however are still the Product Owners, although a crucial role in Scrum. The ScrumAlliance offers a Certified Scrum Product Owner course (‘CSPO’). But… no assessment yet. I don’t want to go into CSP, CSC or CST options because I feel they are heavily over-institutionalized. CSD is too unclear.

The ScrumAlliance verifies knowledge of Scrum against the Scrum Primer, from the Scrum Training Institute. I’ve read both and find the Scrum Guide to have the in-depth Vision of Scrum, while the Scrum Primer is more about concrete practices.

Posted on by — 2 Comments

Definition of… Agile

There is no final ‘definition of Agile’, no silver bullet / fits all approach. ‘Agile’ is not even one tangible method, but holds the common principles to a number of methods, that are as such stated in the Agile Manifesto.

I try to address this topic with the presentation of key characteristics. For both ‘Agile’ and traditional methods. That seems to be very recognizable.

Key characteristics of traditional methods:

  • Plan-Ceremony driven;
  • Single pass waterfall (sequential model);
  • Success = compliancy with predictive plan, i.e. end = original set destination;
    • Progress = ‘deliverables’ (specs/design/code/reviews/signatures);
    • Resisting/blocking ‘change’.

    Key characteristics of Agile methods:

    • Change-People driven;
    • Iterative-incremental process;
    • Success = delivered Business Value;
    • Progress = frequent delivery of working software;
    • ‘Embrace change’. Even encourage change!

    It is quite possible to get organized upon these general principles, and find a way through it and successfully build software. It is however a lot faster and more productive to select an existing, tangible process. Start by implementing it ‘from the book’ to get a firm grip on it. In a next step, it can still be optimized upon specific circumstances.

    And, while you’re at it, have a good look at Scrum. It is the most spread Agile method worldwide, has lots of communities with well-documented cases, is technology-independent and there are great coaches to assist a Scrum transition. A good starting pointing might be Scrum.org…

    Posted on by — Leave a comment

    The upstream adoption of Scrum

    Since 2003 I have been involved in successful implementations of Scrum, through various projects and in different organizations. This was primarily on my local market, Belgium. Since 2010 I started promoting adoption of agility through Scrum beyond my professional consulting activities, as board member of the Agile Consortium Belgium.

    While worldwide the Agile portfolio is going through the Bowling Alley and Scrum is emerging as the Gorilla, my local market seems to struggle to even cross the chasm. One of my re-occurring findings is the lack of upstream adoption of Scrum. I consider it a major impediment.

    Retrospective of a Belgian ScrumMaster

    In my position as consultant I rarely have complete control over the delivery process, and even the decision to actually call it ‘Scrum’, let alone full-scale adoption. But the least I always do is master a project instead of manage it as a traditional command & control-like dictator. I refer to it as my Scrumitude: iterative phasing with end-of-iteration demo’s, mastering a Team into Sprint Planning and self-organization, being a facilitator, removing impediments over being prescriptive, establishing a close relationship with the Business, promoting on-site presence of cross-functional team skills, using visible information radiators and high transparency. All information gets consolidated in a Product Backlog Tracking model I created. The actual course of Sprints and the reality of what the Burn-downs show is used to continually adjust expectations, for better or for worse.

    In the absence of outspoken Scrum, even such stealth application of Scrum results in regular, often perceived as on-time, and on-budget, or better high return delivery with higher satisfaction. And it does make projects fun again. No surprise that downstream adoption of Scrum, i.e. by Teams, end-users and business representatives, is generally huge, outspoken or stealth.

    Although good figures and great, highly visible results are generally synonymous for upstream ‘success’, the Scrum process and its essential causal part in this success seem hard to capture and to accept for many old-skool commandistos.

    • The first upstream obstacles are lower level management that likes to operate below corporate radars. They object the transparency and visibility as they feel personally less beneficial on the ‘success’.
    • The more upstream levels don’t care about the process, just about the figures. In the best case they tolerate a deviant process. An unpredictable and unreliable base for deeper transition.

    What we need is active and explicit upstream support and promotion. Think about operational management (‘pure’ IT), sales divisions, delivery managers and hierarchical management.

    Confessions of a Belgian ScrumMaster

    The success of stealth Scrum is limited because it disguises the essential change. Stealth Scrum is certainly less intrusive, but the leverage of advantages and benefits that will last, is generally wasted. As a consultant it remains a struggle to articulate about Scrum more clearly without losing commercial opportunities.

    PSMIIAnd a tedious effect is that people start instructing me with their fantasies on Agile/Scrum. Which is not why I re-entered the world of Scrum and greatly engage in Ken Schwaber’s Scrum.org. And decided not to let the momentum pass this time. And became Belgium’s first PSM II (in August 2010).

    Posted on by — 2 Comments

    Is that a gorilla I see over there?

    A topic that I frequently run into at customers is the maturity of Agile. I usually present my matching of ‘Agile’ on the Technology Adoption Life Cycle with the Hype Cycle for Application Development. To show the evolution of Agile, and its outgrowing of the stage of anecdotal evidence.

    Specific to the Technology version -for new high-tech paradigms- of the Adoption Life Cycle is the chasm, introduced by Geoffrey Moore. A phase of stagnation between Early Market and Bowling Alley. Of unpredictable length. And some products even never get out of it. Scary.

    In the post-chasm period the viable market forms, and a gorilla rises, an absolute market leader. Alternatively the market leader may turn out to be ‘merely’ a king, much more vulnerable to being overthrown.

    An important and disruptive innovation in itself, Agile is past the chasm. It’s probably in the Bowling Alley, maybe approaching the Tornado. At the same time Agile processes are applied to develop products that are subject to the (T)ALC. Best fit because there’s no time to stabilize into Main Street. And Agile offers just that flexibility while assuring a return.

    At the same time I observe the increasing number of Agile players that is referencing Scrum. Practitioners, trainers, thought leaders, customers, etc. On blogs, forums, in trainings, papers, etc. You name it. Positively (“this is great, we also do it“) or more disapproving (“this doesn’t work, we do it like this“). Although personally convinced that they’d better highlight their own methods’ merits and strengths, I don’t oppose to it.

    And Scrum prospers from it. Free publicity and a trigger to keep moving. I see evidence of the latter in the rise of Scrum.org. More community oriented as an alternative to the ScrumAlliance institute will it open the Scrum offering to a wider audience.

    But it gets very uncomfortable when it gets personal. Quite vicious attacks are regularly launched at the persons behind Scrum and the people doing Scrum, away from the value of the framework.

    Maybe that is exactly the indication that Scrum is indeed emerging as the gorilla of the Agile methods pack…

    Posted on by — 5 Comments

    Unsatisfied? Uncertified? Unvalued?

    When I announced having passed the Professional ScrumMaster II assessment (including getting certified) the reactions were -to say the least- mixed. People I have effectively worked with sent me warm congratulations. People more distant to me seemed more cynical and skeptical. Time to set free your psychoanalytic ambitions!

    I partly share the cynicism, skepticism and unbelief with regards to certification in general in our world of IT, consultancy and software development. But a little common sense makes one don’t consider certification solely, but experience, attitude and personality as well.

    I know that calling people Certified ScrumMaster (CSM) after merely attending a 2-day course isn’t too credible. Can I say to my credit that it was 3 days when I did it in 2004? But that was then. Nowadays the ScrumAlliance requires participants to do an online CSM evaluation.

    And it doesn’t justify any reservations on the PSM program!

    Last year, Ken Schwaber and the ScrumAlliance parted and Ken started Scrum.org (for a couple of reasons). He developed new and updated programs upon effective knowledge assessments. Jeff Sutherland and Ken updated the Scum Guide. To form the Scrum Body of Knowledge.

    The Scrum Open Assessment was created incrementally with feedback of the community and serves as a check-up on the subscriber’s knowledge. No medals attached, just knowing where you stand.

    The Professional ScrumMaster assessments are not open, but require payment. Luckily, payment is no guarantee. You do not just pay to get a certificate. You obtain 85% or more. Scrum.org has no benefits in creating an unnaturally large amount of PSM’s.

    • PSM I is about knowing how the game should be played. Limited pretensions. It’s also included in the fee for a PSM course, the follow-up to Ken’s original CSM. So it is not just about the money.
    • PSM II is about understanding and applying the underlying principles. Answers that cannot be found directly in the Scrum Guide. Often demanding multiple options with (dis)advantages.

    So let no general skepticism stand a correct judgement of the PSM assessments in the way. They emphasize on demonstrable knowledge, over paper certification, which I certainly have come to value more. Reason why I am proud of my PSM II. Though that won’t stop me from being pig-headed in my way of mastering people and projects…

    Note: The Professional Scrum Developer (PSD) is an innovative program on software development using Scrum. Resembling my Quality Loops?

    Posted on by — 6 Comments

    Professional Scrum Master II

    I consider myself not only an early follower of Ken Schwaber’s Scrum.org but also a mental companion on his new journey. Must have to do with the fact that I obtained my Certified ScrumMaster from Ken in 2004 in Brussels and am still fascinated with his straight-forward views.

    Despite my (pragmatic) use & application of Scrum since 2004 (and eXtreme Programming since 2003) I was hesitant to take the Scrum.org assessments. Hesitant, as in opposed to arrogant.

    But… Open Scrum went well (Jan 2010), as did Professional Scrum Master I (Jun 2010). The biggest doubts however I had about the Professional Scrum Master II, frightened by the essay-like topics. But I leaped and took the exam. On 26 August. The start of 2 nervous weeks of awaiting the result. To receive my certification… hooray indeed. #27 worldwide.