Traces of my presence at events (Selected Recordings 2012-2017)

I go to speak at events without commercial or monetary intentions. I primarily go to meet people and share ideas and connect with the Agile communities and Scrum practitioners. On my YouTube channel I have uploaded all recordings of my sessions that are available.

Following is a selection (so far):

2012 – Entering the public domain

In March 2012, at a Scrum.org trainer event, Ken Schwaber checked with me on the possibility of a yearly event about Scrum in the Netherlands. We moved it forward and the first Scrum Day Europe event happened on 11 July of that same year in Amsterdam. My session, “The emergence of the Customer-Oriented Enterprise”, wasn’t recorded, but you can check out my rehearsal of the presentation at the mentioned March trainer event.

Find the presentation at Slideshare.

Note: At the heart of the concepts presented (2012) is the belief I expressed in my book “Scrum – A Pocket Guide” (2013) and the ideas I am building on again in my “re-vers-ify” narrative (2017).

2013 – Scrum for the enterprise

At Capgemini I had already  worked with Ken Schwaber on Agile transformation ideas and Scrum at the enterprise level. As I entered Scrum.org as director for the Professional Series in June 2013, that was our first priority to elaborate on. We presented a first set of ideas at the second edition of the Scrum Day Europe event on 4 July 2013 in Amsterdam.

2014 – Evidence-Based Management

We started focusing more on the inspection part of “Agility Path”. We separated it into “Evidence-Based Management (of software)”. The plan was to present it jointly as the opening keynote of Scrum Day Europe 2014. However, as Ken had visum troubles, I presented it alone.

I had already written a paper about the core ideas of the concept presented. As ideas keep evolving, I started using the term ‘Empirical Management’ and am tending towards using ‘Exploratory Management’ nowadays.

2015 – Scaled Professional Scrum with Nexus

Our focus shifted from organizational transformations back to helping people and teams to employ Scrum. A lot of concerns existed around employing Scrum in the large. Figuring that ‘Scaled Scrum is still Scrum’ we probably ignored the need for too long. We created the Nexus framework, and described it in the Nexus Guide. I presented our approach to Scaled Professional Scrum with the Nexus framework as the opening keynote at Scrum Day Europe 2015.

2016 – The Future Present of Scrum

Scrum has been around since 1995. In the spring of 2015, Ken and I discussed how “Done” was a much misunderstood and certainly undervalued purpose of Scrum. Having created some blog notes about it, I used the 21st anniversary of Scrum (2016) to make it my core speaking topic, as “The Future Present of Scrum (Are we Done yet?)”.

2017 – re-vers-ify

In 2016 I continued my journey of Scrum as an independent Scrum Caretaker. The opportunity to work with diverse organisations and teams helped me consolidate over a decade of ideas, observations and beliefs of Scrum. I realized that all ideas I had been working on before and -certainly- after 2012 were connected. I created a narrative called “re-vers-ify”, or “re-imagining your Scrum to re-vers-ify your organization”.

Too often still the organisational waste, abuse and impediments, ruthlessly highlighted by Scrum, are ignored. Meanwhile organizations grasp for rhythm, focus and simplicity. Re-vers-ify shows a positive path forward, without falsely predicting the end result.

It became my speaking topic for 2017. I presented it as the opening keynote at the first ever Scrum Day Ukraine event in Kyiv on 11 March 2017.

Since 2003 countless people have told me I limit myself by ‘just’ doing Scrum. After 14 years, still, every day is like my first day of Scrum. Every day again Scrum turns out not a limitation but a gateway to options and possibilities to help people, teams and organizations.

Scrum, a forward looking observation (2017)

All events organised in Scrum are designed to be forward looking. Adaptation follows inspection. Feedback from observable results is meaningless if not applied. All assessments, evaluations and inspections we undertake in Scrum primarily serve the purpose of working on the most valuable future. Scrum inspires us to shift our perspective from solely judging the past and checking actuals towards planning and innovating for an unknown future. In short, focused iterations we reflectively shape the future while embracing unanticipated surprises.

This is the spirit through which we act. We act on forward looking observations. This is the spirit through which we can consider the future of Scrum. Rather than glorifying the past of Scrum, we anticipate the value ahead. We aim at surfing the wave. We shape the wave.

THE 3RD SCRUM WAVE IS RISING. WILL YOU SINK? BARELY SWIM? OR WILL YOU SURF?

‘Agile’ started crossing the chasm as from 2005-2006, much enabled by the increasing popularity of Scrum. The Agile way of Scrum became an accepted way of creating and delivering products. In the subsequent 1st Scrum wave a growing number of teams discovered the first-level benefits of Scrum, albeit predominantly from an IT perspective. Organisations moved away from endless sequential phases and gateways, and began exploring the advantages of iterative-incremental delivery. The 1st Scrum wave was mainly about adopting Scrum, a first encounter, the start of a journey of discovery.

grafx-technology-adoption-life-cycle

In the slipstream of the 1st Scrum wave, sub-groups and derivative movements took off, new movements and methods were invented, introduced, launched, and often disbanded again. Divergence in itself is great, unless the overall result is dilution and opacity. Rather than into variety, the divergence turned into scattering, even with Scrum being the actual standard, even with the definition of Scrum being formalised by its co-creators in 2010 in the Scrum Guide. A bowling alley of problems to be addressed appeared, a wide range of pins. Some pins appeared to be left unaddressed by common Scrum implementations. Some pins were raised to challenge presumed weak spots of Scrum, challenges presented as unaddressable through Scrum. On top of this slow evolution, 2010-2011 saw a seemingly sudden desire of large organisations to transition to this ‘Agile’ thing, fast. The tone for the 2nd Scrum wave was set, a wave of diverging Scrum. Scaling became a thing. Parts of the Scrum terminology became standard vocabulary, but at the same time the tangible rules and principles underlying the Scrum framework were pushed to the back, their purpose snowed in under resurrected needs for layers, titles, roles and structures, at scale.

2016-2017. It takes time to replace the industrial views on the creative act of product delivery. Rat races continue, Scrum is underused as a way out. Too often still the organisational waste, abuse and impediments, ruthlessly highlighted by Scrum, are ignored. Yet, more people and organisations than ever continue their quest to stop more hamster wheels, to create more room to reflect, to improve, to innovate. The 3rd Scrum wave is fuelled by the desire, the drive for rhythm, focus and simplicity. Agile and Scrum are recognised as two inseparable ingredients for healthier and more humane ecosystems that deliver better products. The awareness keeps growing that it starts and ends with people, not with procedures, tools or games. People embrace the Scrum values as a catalyst to re.imagine their Scrum, to re.vers.ify their organisation. Convergence appears on the horizon, where the rage of scattering, where the tornado starts calming down.

We sow seeds. We fertilise the grounds. We help converge product delivery initiatives in a Scrum Studio. We help the shift from traditional to empirical management. We envision a future, networked structure, a nervous system of product hubs and distributed leadership. The 3rd Scrum wave is about enacting Scrum, discovering how the well-defined and clearly stated framework of Scrum leaves plenty of room for variation, a diversity of strategies to employ Scrum.

re-vers-ify-nervous-system-annotated

In 2016 Scrum turned 21. We have come a long way. We look forward. We walk on. We re-vers-ify. We re-imagine our organisations.

THE 3RD SCRUM WAVE IS RISING. WILL YOU SINK? BARELY SWIM? OR WILL YOU SURF?

Agility, actually (is an organisational state of being)

Agility is an organisation’s state of high responsiveness, speed and adaptiveness. Agility is an organisation’s state of continual adaptation and optimisation, a state in which each status quo is challenged, by our own will or by external turbulence.

Agility is a state that is a natural fit for the unpredictability so common to the work of complex product delivery and to the markets that organisations operate within. However, it requires accepting that the work is unpredictable, a mental barrier to overcome. Agility is why teams and organisations adopt Agile processes. From that adoption agility increases, a new of working emerges, new organisational ways of learning, improving and constant adaptation, and restored respect for people, re-humanisation.

Scrum helps. The distinct rules of Scrum help. Scrum is actionnable. Agile and Scrum, actually, are two inseparable ingredients in a complex product delivery ecosystem. Scrum can be your foundation for agility. Sprints are at the heart of business agility in generating a regular flow of improvements, updates, learnings and various other sources of value. Organisations discover, experiment and deliver on opportunities from an end-to-end perspective in the fastest possible way. People develop new ways of working; through discovery, experimentation-based implementation and collaboration. They enter this new state of being, this state of agility; a state of constant change, evolution and improvement. Re-humanisation takes place. Innovation surfaces again.

The path of increasing agility via Scrum is inevitably bound to be a cobblestone path. It might take some time to accept that agility starts and ends with people, not with procedures or tools. It might take some time to accept that agility takes time, that agility need not be analyzed, designed and planned. It might take some time to accept that agility occurs:

  • Agility can’t be planned;
  • Agility can’t be dictated;
  • Agility has no end-state.

A time-planned way to become (more) agile introduces unfavourable expectations. Introducing Agile methods to increase agility causes significant organisational change. Several existing procedures, departments and functions will be impacted. There is no way of predicting what needs will be encountered at what point in time, how these will be dealt with and what the exact outcome will be in order to control next steps. It is a highly complex and unpredictable journey. There is no way of predicting the pace at which the state of agility will take root and spread.

Scrum and agility are much more about behaviour than about (following) a new process. A decision to adopt Scrum is a decision to leave the old ways behind. It is not only about accepting but about celebrating the fact that agility is living the art of the possible. It requires the courage, honesty and conviction of acting in the moment, acting upon the reality that is exposed by iterative-incremental progress information. Agility is about doing the best possible at every possible moment, constrained by the means we have and facing the constraints. A time-planned way ignores the essence of Scrum and Agile, that of dealing with complexity via well-considered steps of experimentation and learning. Time-plans simply extend the old thinking. In general a plan will even slow down the overall increase of agility, because serious delays and waiting times are incorporated.

Time-plans create the illusion of deadlines and a final end-state. Agility has no end-state.

Living the art of the possible engages people and accelerates a transformation as it shapes the future, thrives upon the future and what the future might bring. It’s a bright future for organizations that have the vision, the determination and the dedication.

These basic truths must be in the hearts and minds of every person managing, guiding, facilitating, hoping or striving for agility. And even then, it takes time for agility to settle in the hearts and minds of the people impacted. After all, people have been instructed in the wrong behavior of the industrial paradigm for 15 to 20 years, or more. Agility starts and ends with people, not with tools, procedures or games.

 

 

The Agile Paradigm (who said it was going to be easy?)

Grafx - Paradigm shift (Industrial)The domination of software development by a paradigm of industrial views and beliefs, a copy-paste of old manufacturing routines and theories, got us in a crisis. The attempts to overcome this crisis by fortifying the industrial approach are without result. The flaws and problems are huge, known and well documented. The crisis largely continues to this day.

Grafx - Agile ParadigmThe seeds of a new world view were already sown in the 1990’s, and resulted in 2001 in the formal naming of ‘Agile’. A turning-point in the history of software development. A new paradigm for the software industry was born; a paradigm that thrives upon heuristics and creativity. A paradigm that restores the respect for the creative nature of software development and the intelligence of its practitioners.

Yet, many say that Agile is too radical. They keep propagating, to this day, a gradual -if any- introduction of Agile practices into existing, traditional processes. Having witnessed several of such attempts, I am extremely skeptical about such a ‘gradual’ evolution, a slow progression to the Agile paradigm. Because:

  1. A gradual evolution only scratches the surface. New names are installed, new terms, tools and techniques imposed, but the fundamental thinking remains the same.
  2. The mentioned paradigms consist of fundamentally different concepts and ideas, and many are mutually exclusive. No meaningful introduction of Agile practices in an industrial paradigm is possible.

A gradual shift is factually a status-quo. The industrial paradigm remains. A permanent crisis is called upon us.

It requires honesty to accept the mismatch of the old ways, and courageous leadership to embrace the new ways.

Abandoning the old thinking will take time. Scrum helps. Its distinct rules help in getting a grip on the new, Agile paradigm. The limited prescriptions allow immediate action. They allow developing new ways of working; through discovery, experimentation-based learning and collaboration. It is worthwhile the giant leap.

I wish you a 2016 of determination and improvement. I congratulate you with the hard work you will have performed in a year from now.

(Note: much of the above was copied, with some editing, from my book “Scrum – A Pocket Guide“, providing context to my description of the Scrum framework, its rules and roles, and their purpose)

Done is a crucial part of Scrum, actually

If Scrum was to be reduced to one purpose, and one purpose only, that is the creation of a Done Increment in a Sprint. The typical term in Scrum to describe the state of software being releasable is “Done”. All that this state of releasability encompasses is captured in the “definition of Done”.

Done Increments are THE way to achieve agility through the empiricism of Scrum. 

Empiricism

The empiricism of Scrum, the process of regular inspection and adaptation, only functions well upon transparency. Transparency is having insights into reality but is is additionally upheld through standards and agreements, against which inspection and adaptation happens. The definition of Done is such a standard. The definition of Done is part of professional Scrum development. Other standards, like development and engineering standards, might even be derived from the definition of Done.

The frequency of the inspection and adaptation should be high enough to be able to act in the moment yet not too high to preserve the ability to get considerable amounts of work done.

The definition of Done serves empiricism

The definition of Done should be shared, explicit, clear and concise.

A Development Team will use the definition of Done to consider the amount of work to be pulled into a Sprint during Sprint Planning.

The evolution of an Increment is managed via collaborative inspection and adaption of the actual development work against the forecasted Product Backlog and the Sprint Goal; at least on a daily base, possibly sooner. A Daily Scrum assures that the people accountable for the actual development optimize their work plan against new insights and achievements. The definition of Done supports identification of work remaining to get the software to “Done”.

No later than at the Sprint Review, the Increment is collaboratively inspected and adapted with the stakeholders. This inspection opens up the opportunity of incorporating feedback from these stakeholders to identify what is most important to do next. Purpose is the open identification of what is important to do next, not hindered by unknown, unpalatable, unestimatable remaining work.

Releasing the software closes the feedback loop to the market and the users of the software. Releasing sooner is better in order to remain in line with external expectations and experiences. It is the only way to ultimately validate all assumptions (of functionality, and others) built into the product. Not being able to release an Increment at the end of a Sprint, or sooner, impedes agility. The decision of releasing an Increment by the end of a Sprint is a Product Owner decision, as the sole representative of users and stakeholders on the Scrum Team. The Product Owner’s shipping decision should not be constrained by ‘development’ work.

Undone software is best not released. There might be situations in which undone software is consciously released. An extreme crisis maybe? The least to do is make the undone work transparent via Product Backlog, knowing and understanding that any estimate of such corrective work is probably totally off and the nature of the work unplannable. This ‘registration’ does not render an undone release any more professional, and probably the crisis you are hoping to solve with the unrelease, will re-appear because an unrelease will not fundamentally solve it. Unreleases backfire. Probably better to Scrumble.

At the Sprint Retrospective, the Development Team might inspect and revise its definition of Done; incorporating new insights, new expectations, higher standards. Ownership over the Definition of Done lies with the Development Team. It is their accountability to develop software that lives up to the definition of Done. In many organizations the definition of Done is likely to be derived from organizational standards for development quality. A Development Team will enact them, expand them. If “done” for an increment is not a convention of the development organization, the Development Team will create their definition of Done, appropriate for the product.

Regardless, the definition of Done provides transparency over the state of an Increment at the Sprint Review, where this state optimally reflects ‘releasable’.

Done is a crucial part of Scrum, actually

Although no official artifact, the definition of Done is a crucial part of Scrum in upholding transparency over the state of releasability of the software created. No transparency means no meaningful inspections, and no meaningful adaptations of Product Backlog through stakeholder feedback upon review or through user feedback upon release.

In the last updates to the Scrum Guide (most recent: July 2013) the definition of Done was given considerably more attention. Rightfully, as “Done” is absolutely crucial in Scrum.

Here’s how I stressed the importance of Done in my book, “Scrum – A Pocket Guide“:

The empiricism of Scrum only functions well with transparency. Transparency requires common standards to work against and to inspect upon. The definition of done sets the standard for releasable.

 and

The definition of done is essential to fully understand the work needed to create a releasable Increment and for the inspection of that Increment at the Sprint Review. The definition of done serves the transparency required in Scrum in terms of the work to be done and the work actually done.

Branching Done

I was recently contacted by a senior executive of a mid-sized company that is evolving their product development to Scrum. He explained a situation he had been in and wanted my opinion. He accepted me to share his story here (with some abstractions, and calling him Jim) in an open-ended way, inviting the reader -much like he did- to reflect on the purpose and accountability of the Scrum Master and how that role is needed for… well, many reasons still.

Jim’s company started out doing Scrum on some smaller, carefully contained projects with individual Scrum Teams developing clearly separated products and product areas. Through these projects they discovered how iterative-incremental product development increased transparency, and how disciplined engineering practices allowed them to excel. Where Scrum in the beginning was much seen as mainly for IT people, they soon found out the need for a mandated Product Owner representing the internal business and the user base to the teams. They felt that hiring a Scrum Master with three years of experience had been really helpful.

One of these early projects was recently expanded to two teams. Both teams work on the same product and draw work from one and the same Product Backlog. The Product Owner and the Scrum Master perform their roles for both teams.

Jim contacted me after he was invited to and attended the second Sprint Review after the expansion to two teams.

At this Sprint Review the two teams took 60 minutes each to walk everyone through the software functionality they had created. Each team showed the work from their separated code branch. By the end of the Sprint Review, Jim inquired about releasing the software, but got an unclear answer. In the end it boiled down to the teams promising they would have a look at it, and discuss it with the release department who hadn’t been involved so far.

Jim felt like not straining the teams more but an uneasy feeling had crept in. After all, one of the reasons why they started adopting Scrum were their long release cycles, and unclear release dates. It had led to many customer complaints and even losing a couple of important customers.

When he asked for my advice I told him only I was very interested to hear about the conversation I suggested he set up with the Scrum Master. He seemed a bit surprised when I started talking about the role of the Scrum Master.

How about you? If any, where would you situate the accountability of the Scrum Master in this?