Category: Scrum

Posted on by — 2 Comments

Introducing the Scrum Caretakers initiative

Discovering what drives me is a never-ending journey (1). Starting with eXtreme Programming and Scrum in 2003 was a life changing experience.

My work for different consulting companies (2001-2012) was spent on Scrum. I authored a pocket guide to Scrum in 2013. I went to work with the Scrum.org team and Ken Schwaber in 2013. In 2016 I decided to further my journey of Scrum on an independent basis.

Discovering what drives me is a never-ending journey (2). The stable essence is that:

I care about people. I care about Scrum. I care about helping people create better products and a more humane workplace through Scrum. I care about helping people re-imagine their organisations.

I detached myself from any fixed organisational structure. Of the tangible goals I had in mind, one was to start a community initiative for Scrum across Belgium and the Netherlands, the Scrum Caretakers.

Belgium is where some of my core insights in Scrum were created (2003-2010). Since 2010 however I have worked primarily in the Netherlands. Scrum is completely under-used in Belgium. Scrum is huge in the Netherlands, and splintered. I initiated the Scrum Caretakers community, currently already materialised as a meet-up group.

Anyone can join, from any place in the world, and have access to whatever it is we create. Actual get-togethers are organised alternately in Belgium and the Netherlands for the time being.

Posted on by — 4 Comments

Start optimizing your Scrum (stop filling positions)

Scrum is a minimal, yet sufficient framework for self-governing product eco-systems to create, evolve and maintain complex products.

Scrum defines the in and the out of the system:

  • The system works on ideas, suggestions and options that are converted into Product Backlog for reasons of transparency and manageability.
  • The system produces a valuable Increment of product, a release candidate, no later than by the end of a Sprint.

Scrum defines 3 complementary, peer accountabilities to balance all activities required for modern, Agile product development:

  • A Development Team converts the desirements ordered via the Product Backlog into valuable Increments of product in no more than a Sprint’s time, where a Sprint is no more than 4 weeks and often shorter.
  • A Product Owner optimises the flow of value, balancing innovative, novel ideas against desires, wishes, suggestions and needs stated by the user base, the stakeholders, the organisation, the teams.
  • A Scrum Master fosters an environment in which the Product Owner, the Development Team, and the organisation get the most out of Scrum, using many possible management techniques.

The system called Scrum might consist of multiple teams creating, evolving and maintaining one product. It shouldn’t supersede the minimalism of Scrum. The system works off of one Product Backlog and creates valuable product Increments through the accountabilities foreseen by Scrum.

The context of multiple teams creating one product is often interpreted as an obligation for every team to be a Scrum Team, and every team to be a complete and full-time feature team.

Scrum doesn’t define accountabilities as an excuse to fill positions. Scrum thrives on understanding the accountabilities rather than on blindly filling positions and claiming titles. Scrum doesn’t instruct a uniform, detailed layout of the internals of your system.

Use Scrum to optimise the whole. Optimise your Scrum. Employ Scrum to build a product with multiple teams. Your system is expected to be a feature system, a system capable of producing valuable Increments of product, no later than by the end of a Sprint, regardless the setup of the teams. The accountabilities are expected to be fulfilled, regardless the number of people it takes throughout your system.

Minimally, for n teams working on one and the same product:

  • There are n Development Teams, where the composition of each team is likely to depend on your context. Ultimately, the combined teams need to be able to produce valuable Increments while maintaining the integrity of the product. They self-organise to optimise.
  • There is 1 Product Owner, and most likely a distribution of product ownership. The form of the distribution depends on your context. Ultimately, the flow of product value needs to be unhampered, frequent and targeted.
  • There are 1-n Scrum Master(s), depending on your context. Ultimately, the eco-system and the environment in which it operates need sufficient and sufficiently provocative support, guidance, protection and coaching.

Frameworks like LeSS, Nexus and Scrum@Scale offer diverse strategies at scale that might help in your situation if you are unable to keep your system minimal. Consider your specific needs and opportunities to optimise carefully.

Posted on by — 3 Comments

Scrum, a forward looking observation (The 3rd Scrum Wave)

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?

Posted on by — Leave a comment

Re.vers.ify (essential introduction)

By the end of 2016, Co-learning organised a webinar about “Re-thinking the organisation”. I feel humbled for sharing my views next to those of the other presenters James Priest (Sociocracy 3.0) and Jürgen De Smet (founder of Co-learning and collaboration architect).

I introduced “re.vers.ify“, the consolidation of over a decade of experience, ideas, beliefs and observations of Scrum. In the recording of my part you will find a fair, 15-minutes summary of my essential and current thoughts and drivers:

Re.vers.ify is an act, an act of simplicity, rhythm and focus. Re.vers.ify is a way for people to re.imagine their Scrum, intentionally emerge a Scrum Studio and -ultimately- re.imagine their organisation.

Posted on by — Leave a comment

Speaking Engagement 2017 (re-vers-ify)

Ullizee -Seal 2104I’ve been asked to go present at some events in 2017. It got me into more clearly describing what my speaking engagement will be about. Download the PDF “2017 Speakers Topic Gunther Verheyen re-vers-ify“.

I foresee spending much of my energy on introducing “re-vers-ify” to the world, a way for people to re-imagine their organisation by re-imagining their Scrum.

There are various fascinating and -probably- valuable strategies available to scale Scrum. They are however all situational. I help people and organisations move forward, regardless how long they have or have not been adopting Scrum, or the scale at which they operate. I always introduce the simplest and most core basics of Scrum first. I highlight their purpose and how they serve business agility. I find that it enormously draws on people’s imagination but it also excites them greatly; identifying a product as the application domain of their Scrum, having a Product Owner with the ability and mandate to act as a Product-CEO, producing a Done version of product by the end of every Sprint (regardless the number of teams).

common-scrum-challenges

I have observed how imagination can set an organisation apart. Imagination often distinguishes innovative from lagging organisations. Any organization can be re-imagined, re-vers-ified, to exploit its intrinsic potential to innovate and lead.

The many adaptations possible through Scrum provide a safety net, actually. Scrum thus creates room for action and discovery. Organisations can re-imagine their Scrum to converge their product delivery into a Scrum Studio. Over time divisions dissipate into a structure of product hubs interconnected through purpose and distributed leadership. Creativity and innovation emerge. People, teams and the organisation prosper.

re-vers-ify-nervous-system-annotated

I have consolidated over a decade of his experience, ideas, beliefs and observations of Scrum in re-vers-ify. In my upcoming talks I will introduce how the deliberate emergence of a Scrum Studio is the current way forward to re-vers-ify.

Re-vers-ify is an act of simplicity, rhythm and focus. Simple, not easy.

On 23 December 2016 I lift a tip of the veil at a webinar I am participating in together with Jürgen De Smet (collaboration architect at Co-learning) and James Priest (Co-Founder of Sociocracy 3.0)

Looking forward to catching up with you in 2017.

Gunther

Posted on by — 2 Comments

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.

Agility (inconvenient truths)

 

 

Posted on by — 2 Comments

Challenging Sprint Retrospectives

An essential question in the use of Scrum seems to be ” How can we make our (Sprint) Retrospectives more fun? ”

When digging a bit deeper, I always end up puzzled. I always end up wondering about the value and the level of team engagement. I wonder what sort of fun they are looking for. I wonder about the understanding of Scrum. I wonder about the subject of inspection and adaptation at their Sprint Retrospective. I wonder what purpose they are using Scrum for.

I wonder because Done Increments are at the heart of Scrum, crucial to optimally use empiricism as a way to increase agility. I wonder about the real purpose of a Sprint Retrospective when so few teams are able to actually deliver releasable versions of product, no later than by the end of a Sprint, Sprint after Sprint after Sprint. And that inability only increases proportionally, if not exponentially, with the number of teams when delivering one product.

If Scrum was to be reduced to one purpose, and one purpose only, that is the creation of a Done Increment in a Sprint.

Not achieving that purpose today is not failure. Failure is to stop moving towards that purpose. Failure is to stop inspecting and adapting towards that purpose. Not creating Done, releasable versions of product means sub-optimal use of Scrum. The danger is to stop challenging that status-quo.

Understanding that Scrum Masters are all about helping teams and organizations in understanding and enacting Scrum, following might be a great way to start your next Sprint Retrospective:

  • Scrum Master: “Have we delivered a Done, releasable version of product this Sprint?”
  • Team: “No.”
  • Scrum Master: “What can we do about that?”

Next to checking in with the team on their sense of engagement, how is that to kick off a professionally challenging Sprint Retrospective? Wouldn’t you expect that to initiate some serious reflections? Wouldn’t you expect the team to start initiating improvements that will help them and the organization get more from employing Scrum? Does that not lead to considering what actually is defined as “Done”, and what is needed to achieve that state of work and quality?

Committed, connected and engaged people will have serious conversations about:

  • How to increase effectiveness through collaboration, autonomy & self-organization?
  • What skills & knowledge are needed and (un)available?
  • Are our development practices & standards appropriate and up to par?
  • How are our access, knowledge and use of infrastructure, tooling & automation?
  • What are the quality standards & guidelines that we should take into account?
  • What are the toughest Impediments? Does our Scrum Master know? Can we help in the removal of them?
  • How can we increase our focus? Can we stop attending external meetings? How can we eliminate other forms of work of low value?

How is that as a start for identifying some ‘fun’ experiments and improvements in the next Sprint?

I that doesn’t engage people and appeal to their sense of professionalism, check what is needed to increase the level of team engagement. If reflecting, considering and investigating such questions doesn’t engage people, find out what is killing engagement.

I wish you fierce, focused and engaged Sprint Retrospectives. It’ll be seriously fun. Fun and happiness are important. Engagement however is the key. Fun is no replacement for team engagement. Fun techniques are no replacement for serious conversations.

Posted on by — 1 Comment

A simple framework for complex product delivery (in 3 minutes)

verheyen-gunther-scrum-a-pocket-guide-2016By the end of November 2016 the 5th re-print of my book “Scrum – A Pocket Guide” will be available, with a re-designed cover.

I wanted my book to reflect the simplicity of Scrum, a simple framework for complex product delivery.

As part of this re-print my publisher Van Haren Publishing kindly asked me to create a short video introduction to Scrum, of preferably no more than 3 minutes. The time constraint helped me focus. It helped me keeping it simple, just like Scrum.

What I say in the video was based upon following prepared text:

Scrum is a simple framework for complex product delivery.

1/ Scrum has been around for a while. It was officially introduced to the general public in 1995. Since then, as more and more people, teams and organizations started using Scrum, Scrum became the most adopted method for agile product delivery. At the same time, Scrum grew lighter and lighter, thereby, in a way becoming less and less complete and ‘perfect’. Prescribed practices and techniques were gradually removed from the official definition of Scrum, The Scrum Guide. Scrum turned into the framework it was always designed to be, a framework upon which people devise their own solutions, create their own working process. A Product Owner brings product ideas to a Development Team. No later than by the end of a Sprint the team turns these ideas into releasable versions of product. Sprints take no more than 4 weeks, and are often shorter. The Scrum Master creates and fosters an environment for such self-organised and creative collaboration to happen.

Scrum is a simple framework for complex product delivery.

2/ Scrum not only restores simplicity, Scrum brings empirical process control. All elements of Scrum support the process of regular inspection and adaptation. Empiricism is the way for people, teams and organisations to deal with the complexity, uncertainty and unpredictability typical to product development. The Scrum events set the frequency of the inspection and adaptation process. The artefacts provide transparency to all information required. As all waste has already been removed from Scrum, the framework is highly cohesive. Every element has a clear ‘why’, a clear purpose. Omitting any core elements breaks the cohesion, and is likely to cover up existing problems and impede the transparency required to continuously adapt, to be agile.

3/ Scrum, when employed well, allows a continual discovery of what is possible, what is not, of what works, what doesn’t work. Throughout this journey of discovery, the value of the work done is incrementally optimised. Product is regularly delivered to the market. It is extremely helpful to have a simple, yet proficient, tool like Scrum in highly unstable circumstances.

4/ Employing Scrum is a journey in itself. Mastering Scrum takes practice and time.

Posted on by — 7 Comments

A simple framework for complex product delivery (in 100 pages)

From March to June 2013 I created the book “Scrum – A Pocket Guide (A Smart Travel Companion)” for Van Haren Publishing (Netherlands). Although I had already written much about Scrum, it was really, really hard work. I wanted the book to be about its subject, not its writer. I wanted the book to be concise, yet complete. I wanted the book to reflect the simplicity of Scrum, in its appearance, tone, language, expressions, sentences.

Since its initial publication (November 2013) my pocket guide to Scrum was re-printed 3 times (January 2014, June 2014, November 2015). In April 2016 my Dutch translation was published as “Scrum Wegwijzer (Een kompas voor de bewuste reiziger)”. And two friends of Scrum are currently going through the really, really hard work of creating a German version, which will probably be named “Scrum Taschenbuch” and be available in 2017. And somewhere along the road I experimented with setting up a Facebook page for my book.

This is beyond any expectation I might have had handing in the first manuscript half way through 2013. I am totally humbled, and sometimes overwhelmed, by the continual appreciation of the book’s buyers and readers.

verheyen-gunther-scrum-a-pocket-guide-2016I want to share that a 5th print of the English version is on its way (end November 2016), holding a NEW COVER. The content of the book hasn’t changed. I was fortunate to have described the Scrum Values already in my book. The only change was the update to my personal history, as is also reflected on my website.

Thank you, readers. Thank you, publisher. Thank you, fellow Scrum Caretakers!

To support the update of my book, my publisher asked me to do a 3-minutes introduction to Scrum, a simple framework for complex product delivery. The time constraint helped me to keep it simple, just like Scrum.