Category: Werk / Work

Posted on by — 4 Comments

A Software Development Profession

Creative, artful thinking and craftsmanship are ESSENTIAL QUALITIES for any software developer. But shouldn’t software development be about more than an act of art, a craft in best case? Isn’t there a need to add professionalism to it? Shouldn’t software development be a profession?

It is tempting to believe that software development already is a profession. After all, many people are employed in developing software, making a living out of creating and sustaining the working code of software products and services, as a team or as individuals. Many more are employed in and make a living out of all the side-activities in the wider software development industry; like funding, exploiting, selling, promoting software products and services. This however is not sufficient to state that software development already is a profession.

Some take their dreams for real and call software development a profession. For others it is more a matter of pride, status or ego to say they are part of a profession, instead of an artisan discipline. That still is not enough to state that software development already is a profession.

A profession has regulations, codes, expectations and rules, all building upon a recognized body of knowledge. A profession sets explicit expectations on ethics, conduct and behavior to be demonstrated by any member of the profession. Official exams are in place for members to demonstrate a level of required skills and knowledge before receiving an attestation, and the permission to bear an official title that is protected and reserved. A healthy profession’s regulations and standards have a purpose, a purpose that goes beyond self-serving the profession and the profession’s institute. All regulations and standards should serve to assure the best possible execution of work in order to protect the people and organizations taking part in or being subject to the profession’s activities and its outcomes, and the decisions taken as part of it.

It is difficult to predict if and when software development might transform into a profession. It seems unlikely in a short term. There is the gigantic amount of software development work, there are the endless variations of what might be considered ‚software development,’ the absence of a widely accepted definition and understanding of ‚software development,‘ disagreement over the work activities that should or should not be part of the profession.

Reasonable doubts may be expressed on whether being a profession will augment the quality of service, avoid charlatanism, etc.

Furthermore a variety of people and instances may have personal, political, career, financial or other interests in software development, possibly even outside of the activity itself. Such people and instances might see regulation as a threat to their interests. Or might see it just as a limitation to their artistic freedom. Not to speak of the difficulty in growing a body, ethics, assessments, instructional guidelines and a code of conduct that would be widely accepted within the industry.

Where there are many elements that probably impede software development from growing into a regulated profession, there are also very valid reasons why software development would be better off if it transformed into a profession.

Not the least reason is the overwhelming and crucial presence of software in society and our daily lives. Software has become increasingly vital to society. A major shift is happening. Software products and software services are at the front and at the back of many public, industrial and consumer services and facilities. Software no longer is a ‚nice to have,’ for amusement purposes only. Software is at the heart of the economy. Software is core to many, often even critical, services in the private and in the public domain; financial services, taxes, energy, retail, health care, education, defense, telecommunication, transport, the automotive industry, just to name a few. Numerous organizations thrive on software. Even when they are not software companies, their services largely depend on software.

The omnipresence of software leads to a huge demand for talented and skilled software development people. The demand for professionalism that goes beyond talent and skills is less acknowledged but equally important in the light of the crucial functions of software in society. It would be comforting to know that the level of professionalism shown in the industry grew at the same rate as the growth of presence and criticality of software products and services itself, although even a higher rate is required.

Software development deserves professionalism in doing and in managing it. Such professionalism would benefit much from being structured in a profession.

This post is one of the inquiries I have planned into the values of professionalism in software development and the potential of the scrum framework to induce the formation of a software development profession. A matter of incremental writing. I hope you enjoy it, and the future follow-ups and iterations.

Posted on by — 5 Comments

Scrum – A Pocket Guide (3rd impression)

Gunther Verheyen, Scrum - A Pocket Guide (A Smart Travel Companion)Early 2013 I wrote the book “Scrum – A Pocket Guide“.

It was published in November 2013 by Van Haren Publishing. The pocket format used by my publisher coincides with the sub-title of the book “A Smart Travel Companion” and my views of Scrum as a journey, not a destination. Scrum is a journey toward increased agility, and my book is designed as a small guide that any traveler can easily take along.

Here’s what some of my best friends in the world of Scrum said about “Scrum – A Pocket Guide”:

Best description of Scrum currently available.

says Ken Schwaber, Scrum co-creator.

The book on Scrum I wished I had written.

says David Starr, also known as ‘Elegant Coder‘.

My publisher now informs me that the third impression is about to be produced (June 2014). It is still the first edition as the content is stable. The second impression dates from February 2014. I am humbled by this success and grateful for the appreciation.

If you have read the book, leave a review at Amazon UK, Amazon.com, GoodReads or one of the other shops where the book can be found. It provides me and potential readers with very valuable feedback.

Although Van Haren Publishing has its head quarters in the Netherlands, they have a great global distribution network. Here are some sources where “Scrum – A Pocket Guide (A Smart Travel Companion)” is available from, in varying formats:

And find many more search results at Google (24900 results), Bing (1110 results), Yahoo (1140 results).

Posted on by — 8 Comments

The Product Owner – An Entrepreneur

A vast majority of software development work concerns new product development. Every software product is essentially unique. We create previously non-existing products, suites, integrations and product extensions. We never create the same product twice. We expand existing products into the new product area. Competition, market expectations and technologies move so fast that acquired concepts, practices and approaches are outdated by the time they become well adopted, forcing us de facto into new product development anyhow.

Software development, as new product development through and in complex conditions, requires a startup mindset, no matter the size or age of the product or the master company. The Product Owner, as promoted in the Scrum framework, becomes an Agile Product Manager, the product’s president, its mini-CEO, an entrepreneur. The rise in complexity and uncertainty renders big plans into meaningless waste. The Product Owner drives iterative development from an exploratory attitude, aiming at incremental progress through continuing discovery and validated learning.

Every Sprint has a Sprint Goal as next horizon to work against. The Sprint Goal describes a (business) challenge, from an assumption of (market) value for the (Increment of) product. The outcome of a Sprint provides an important learning option. But the learning is only meaningful when it can be assessed against the product’s external impact and adoption; in affirming or negating the assumption of value underlying the Sprint Goal. The goal of the learning is to find out whether an opportunity is real, whether there is an audience willing to use the product, whether the audience appreciates the delivered functions.

In the absence of a release, value remains an obscure assumption. It is a major unknown and a risk for further investments. The unknown remains unresolved, and the risk is out of control, until the product is brought to market; be it a contained market segment, be it a limited or the full user base. With every Sprint without an actual release, the risk increases exponentially that the Product Owner runs out of tune with the evolving market and is wasting money, time and creativity. Increments of product, seemingly incomplete but offering minimal usable feature sets, provide the foundation for validated learning. Users need it to provide the Product Owner with feedback on the actual value of the performed work, the base to decide on the best future direction of the product. No document, design, paper document or simulation provides the same, high level of validation. Without that ultimate validation no informed decision over strategies or tactics can be taken, not in the least the decision whether to continue on the chosen path or to change direction.

Learning requires not only goals and feedback loops, but also measurements and data to support the validation process. Evidence of value is needed to confirm or contradict the assumptions. Evidence-Based Management can guide the entrepreneur and the stakeholders in their investment decisions.

Scrum can be at the heart of such entrepreneurship. Scrum frames the creativity of people to better deal with complexity and uncertainty. The empirical foundation of Scrum is a structured way to steer experimentation and discovery through frequent validation. In a situation where uncertainty is too big to plan, it is a way to make real progress; progress that is founded in reality, not in plannified imagination.

Seeing the Product Owner in Scrum merely as a requirements engineer, a requirements provider or someone to prioritize a preset Product Backlog is unlikely to help organizations capitalize on the entrepreneurial potential of Scrum. Seeing Scrum as a goal in itself results in gazing at internal performance, volume (of features, of hours, of points) and productivity (velocity or derivatives). Scrum is designed as a mean, a mean to maximize the value of software; value to the market and value to the organization and its people. Scrum is designed to make progress, grow and prosper trough validated, incremental learning. The Product Owner, the owner of the product, takes up the essential role of entrepreneur.

In today’s complex and unpredictable world, Scrum can be the engine of innovation and exploration. It is a choice though. It is your call on how you want to use Scrum.

Posted on by — Leave a comment

Happy Scrum Year

I hope your beginning of the year 2014 was as good as mine was. I wish you a great future no matter!

Crossing from one year to another is often a time for some retrospective introspections. It is a time where we more naturally step away from the daily, monthly and quarterly rush to look back and learn in the face of the upcoming times. As a result, but even besides it, it is also a good time to reground ourselves. Obviously we should retrospect and reground more often, but let’s say that this is a good time to absolutely do it.

My life has much to do with Scrum (below picture has some 2013 highlights). Here are some simple foundational aspects of Scrum I’ve ingrained over the years. They have often helped others to keep grounded or reground. These are bare basics that may seem non-essential at first sight. They have little value when respecting them. However, they become more essential when not respecting them. Not respecting them diminishes credibility in the communities, and it damages how Scrum is seen outside of the communities.

  • Stop calling Scrum a ‘methodology’. It is not. It is a framework. Note that we have even overcome the perception of Scrum as a method for ‘Agile project management’, and the Scrum Master as an ‘Agile project manager’. Focus on the software product, continuous discovery and value.
  • Stop writing Scrum in capitals (“SCRUM”). Scrum is not an acronym, nor an abbreviation. Write “Scrum”.
  • Cherish that Scrum is incomplete. It is by design. This is not a restriction nor a dysfunction. It takes away the illusive and deceptive certainty that from the method itself every possible answer, for every possible situation, at any possible time can be deduced. It actually applies to any method but only Scrum makes it an explicit tenet. Use Scrum as a foundation, and apply the ScrumAnd thinking to address your specific problems and situation.

Happy Scrum Year (2014)

Posted on by — 4 Comments

Moving to the home of Scrum

Why I look forward to working with Ken Schwaber and being part of Scrum.org, the home of Scrum.

Less than a year ago I was wondering about rather surprising evolutions in my professional life of Scrum. I retrospected to find that some things take time, can’t be rushed, let alone be predicted. Ending up with the feeling of being carried to places one never imagined of entering.

That was June 2012. Now is April 2013.

Over the past years Ken Schwaber and I have developed, almost by accident, a great personal and working relationship. Beyond that, I have an awesome contact and understanding with the Scrum.org team. Both aspects contributed to my well-being, made me feel good, respected, cherished even at times. And that was just fine. It helped, it inspired me in my work, it gave me opportunities to bounce ideas off.

Very recently, my daily times and work got into turbulence, with my stress levels going red. I realized that few people understand, understand what drives and motivates me. Hmm, some would say it’s just frustration born out of stubbornness and impatience. Ken and I tightened the relationship. Until we decided to move it to a formal level. And in no more than 1 week we completely arranged for my move to the home of Scrum and become part of the Scrum.org team.

It wasn’t planned. It happened. It emerged from a chaotic situation of doubts, searching, thinking and many considerations.

Who would have guessed?

Being a bit of an anarchist myself, I consulted with knowledgeable dilettante people in that 1 week. Opinions were unanimous: it won’t be a picnic, it will be an adventure, highly challenging, but fascinating and brilliant. Hmm, Ken himself says it will be a walk in the park. But that’s probably because he knows of many past motions that I have gone through. And, despite some controversy and him being a mule, few people would doubt Ken is an honorable, intelligent and trustworthy person to work with.

Luckily we consider ourselves just about weird enough to work with each other. We are both impulsive, impatient. He’s a mule, I’m stubborn. We have much in common; above all we seem to share many views and values. We go for vision, focus and creativity. And I am proud to be creating a little room of the house of Scrum in Antwerp, Belgium, Europe. I’ll be joining a great team, and serve the communities of Scrum practitioners, promoters of Scrum and our Scrum.org Professional Scrum trainers; thriving on autonomy to work on my mastery in Scrum and Enterprise Scrum from the purpose of making this world a better place to live and work in.

Type I behavior: A way of thinking and an approach to life built around intrinsic, rather than extrinsic, motivators. It is powered by our innate need to direct our own lives, to learn and create new things, and to do better by ourselves and our world.

Ken and I made up a little news announcement to express our excitement. Find it here: News – Ken Schwaber and Gunther Verheyen tighten relationship.

Scrum.org Logo

Posted on by — 1 Comment

Few People Understand

Many people spend their time, full-time, on elbowing a career, improving their personal position, aiming at a promotion, planning a next strategic move, working on political strategies, making more money, ripping off people, whatever it takes.

Few people understand what motivates me. Few people understand:

  • My drive to make our world a better place to live and work in;
  • My apathy for titles and hierarchy;
  • My respect for people as the core of my actions and being.

Few people understand that no promotion, no bonus, no pseudo-moral bribery, no threats have changed or will change these inner drives. Few people understand that no hierarchies keep me from addressing people’s issues, challenging the status-quo or experimenting with improvements.

Few people have the mental openness to understand that I care only about the content of my work, about working with people, about my autonomy (in team, time, tasks and tools, as described in Daniel Pink’s Drive). Don’t come to tell me what you want from me, or try to use me for power games or self-promotion. It only wears me out, and only causes me to respond emotional and unexpected (much to my own dismay). Come to work with me and great results may emerge.

I share this reluctantly. It is not a pose. Maybe this one-time notice helps. Maybe it helps you to see why we don’t get along or why you feel ignored. In the meantime I have the best work and personal life possible, the greatest career possible; by not minding my career.

Posted on by — Leave a comment

A Servant King?

purple-badgeIn 2012 one of the communities at my employer found a fun way to reward people. The community handed out virtual badges for specific achievements. The top badge collectors became kings. The kings recently fought a ‘battle’ to determine who would be the conqueror.

The kings had to present themselves to the battle audience with a little movie. My movie was co-created with a terrific colleague and member of El Porco, who I hold accountable for the poetic expressions that might indicate how I’m perceived. Better than any spoken statement could be.

By the way, I gloriously and graciously failed to win the battle.

Posted on by — Leave a comment

Writing Scrum Writings

On top of managing the agile offering of Capgemini (Dutch description here) as a Product Owner and mentoring our Scrum coaches and Scrum trainers I also give Professional Scrum trainings.

Scrum.org-Logo_with_taglineAfter my classes I send out a thank you to the participants in which I include some guidelines to prepare for the online assessment they get access to. I also point people to some background readings. Over time I have created a small library of blog notes I’ve written from which I can select some to refer attendants to for additional information on top of the courseware:

I always pick some of following topics to add:

Fyi. have a look at the most beautiful location I have ever trained in.

Posted on by — 3 Comments

Fixed Price bids. An open invitation to bribe, cajole, lie and cheat.

I have been fortunate. Because some things take time and I have had the time to experience Scrum deeply before the demand rose sky high at my local markets. Time and experience formed the foundation upon which I build in some larger scale Scrum transformations that I am involved in.

I have learned much. I have much to learn. Yet, some people ask for my opinion.

A frequently recurring question is on the combination of agile and fixed price bids (and contracts). Here are my thoughts:

I have an opinion

Fixed price bids are an open invitation to bribe, cajole, lie and cheat.

  • Fixed price contracts introduce a blaming culture. They don’t aim at collaboration and sharing but at shifting all risk to one of the contracting parties. It invites people and organizations to be dishonest and fight in order not to take the blame (and the penalties). It might end up with the supplier financially getting hung, or the requester getting bad quality or not getting work by devious (and clause-wise) omission.
  • Fixed prices deny the very nature of our business. Software development is complex and creative work. There are a lot of elements that influence process and progress, and the number of unpredictable elements surpasses the number of predictable ones.
  • Fixed prices thrive on the belief that time, budget and scope can be fixed and planned upfront. Although everybody (at least off the record) acknowledges the truth in the metaphor of the iron triangle of software development, few seem to say it aloud. Hereby, fixing time, budget ànd scope creates only one certainty, i.e. low quality.

I have experience

Fixed prices define ‘success’ as the predicted combination of in-time+on-budget+promised-scope. Research by the Standish group has shown that agile is more successful than a traditional approach, even against these old criteria. This is not a reason to promote the combination! Yield rate is better but still low by setting the wrong expectations in the context of software development, i.e. that the unplannable can be predicted in a plan.

In the early years of my life in agile, I have delivered several fixed price projects successfully with Scrum. I even developed a framework for it. Still, from a contracting point of view it introduced the notion of ‘fixed price-negotiable scope’. Every single time that this notion was neglected or ignored I ended up in a one-way scope negotiation situation. The bleeding, the pain and the war situations never positively contributed to quality, time to market, user satisfaction, ROI, TCO. Blaming and penalties just appeal to a primitive sense of revenge.

In our Professional Scrum courses we work with the people in the class to figure out options to use Scrum. We try to facilitate bottom-up knowledge generation. We consider parameters and complexities that influence IT and software development, to find that in general we can’t be sure we have them all, and that at least some of the known ones are still quite unpredictable.

Agile via Scrum restores the understanding of the true nature of software development, and offers new ways of working and control to deal with uncertainty. It helps us to shift from the industrial to the creative paradigm and to accept that software development and fixed price contracts are not fit for each other.

I have a dream

Against all experience in, proven low yield rate, failures, burnt-out people and caused distress, the belief remains that a fixed price contract offers certainty. Although there is a tangible and incredible way to deal with the natural uncertainty of software development, Scrum. Scrum allows us to collaborate and behave as partners. We can jointly evolve, learn and check regularly on what does/does not work. But it still requires the first, huge step to let go of the false belief in planned certainty.

I have a dream; the dream that IT professionals stop offering on fixed price bids. Because it is unethical, risky and untrustworthy to make that kind of hard-coded promises in a complex and fast-changing environment. It is… unprofessional. And there is a great alternative option.

Posted on by — Leave a comment

Training Room with a View

I was recently in Offenbach (near Frankfurt, Germany) to facilitate a Professional Scrum Master training for German colleagues. Our learning & development center in Munich had set up the training in the best room I was ever able to do a training in. We had the 30th floor of the gigantic City Tower completely for us. And it offered a terrific view over the area and lots of daylight in the room.

Was it the location? The frequently passing airplanes? Or the sheer enthusiasm of my colleagues? Fact is that it was truly one of my most enjoyable Professional Scrum journeys so far…

Fyi. The City Tower has a height of 120m, and the top floor is the 31st (so still one above us). The tower is not completely taken by Capgemini, by the way…