Year: 2017

Posted on by — 3 Comments

Scrum Vocabulary (updated)

Driven by the prospect of an Italian translation of my book “Scrum – A Pocket Guide” I decided to revise it slightly; minor tweaks of words and terms, although a lot of them.

As part of my revision, I also updated the Scrum Vocabulary of my book:

  • Burn-down Chart: a chart showing the decrease of remaining work against time.
  • Burn-up Chart: a chart showing the increase of a parameter, e.g. value, against time.
  • Daily Scrum: a daily event, time-boxed to 15 minutes or less, to re-plan the development work during a Sprint. The event serves for the Development Team to share the daily progress, plan the work for the next 24 hours and update Sprint Backlog accordingly.
  • Definition of Done: a set of expectations and qualities that a product must exhibit to make it fit for a release in production.
  • Development standards: the set of standards and practices that a Development Team identifies as needed to create releasable Increments of product no later than by the end of a Sprint.
  • Development Team: the group of people accountable for all incremental development work needed to create a releasable Increment no later than by the end of a Sprint.
  • Emergence: the process of the coming into existence or prominence of unforeseen facts or knowledge of a fact, a previously unknown fact, or knowledge of a fact becoming visible unexpectedly.
  • Empiricism: the process control type in which decisions are based on observed results, experience and experimentation. Empiricism implements regular inspections and adaptations requiring and creating transparency. Also referred to as ’empirical process control’.
  • Forecast: the anticipation of a future trend based on observations of the past, like the selection of Product Backlog people believe they can deliver in a Sprint or in future Sprints for future Product Backlog.
  • Increment: a candidate of releasable work that adds to previously created Increments, and – as a whole – forms a product.
  • Product Backlog: an ordered, evolving list of all work deemed necessary by the Product Owner to create, maintain and sustain a product.
  • Product Backlog refinement: the activity in a Sprint through which the Product Owner and the Development Team add granularity to future Product Backlog.
  • Product Owner: the person accountable for optimising the value a product delivers by incrementally managing and expressing all product expectations and ideas in a Product Backlog; the single representative of all stakeholders.
  • Scrum (n): a simple framework for complex product delivery (1); a simple framework for complex problem management (2).
  • Scrum Master: the person accountable for fostering an environment of Scrum by guiding, coaching, teaching and facilitating one or more Scrum Teams and their environment in understanding and employing Scrum.
  • Scrum Team: the combined roles of Product Owner, Development Team and Scrum Master.
  • Scrum Values: a set of 5 fundamental values and qualities underpinning the Scrum framework; commitment, focus, openness, respect and courage.
  • Sprint: an event that serves as a container for the other Scrum events, time-boxed to 4 weeks or less. The event serves getting a sufficient amount of work done, while ensuring timely inspection, reflection and adaptation at a product and strategic level. The other Scrum events are Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective.
  • Sprint Backlog: an evolving overview of the development deemed necessary to realize a Sprint’s goal.
  • Sprint Goal: a concise statement expressing the overarching purpose of a Sprint.
  • Sprint Planning: an event marking the start of a Sprint, time-boxed to 8 hours or less. The event serves for the Scrum Team to inspect the Product Backlog considered most valuable and design that forecast into an initial Sprint backlog against an overarching Sprint Goal.
  • Sprint Retrospective: an event marking the closing of a Sprint, time-boxed to 3 hours or less. The event serves for the Scrum Team to inspect the past Sprint and establish the way of working for the next Sprint.
  • Sprint Review: an event marking the closing of the development of a Sprint, time-boxed to 4 hours or less. The event serves for the Scrum Team and the stakeholders to inspect the Increment, the overall progress and strategic changes in order to allow the Product Owner to update the Product Backlog.
  • Stakeholder: a person external to the Scrum Team with a specific interest in or knowledge of a product that is required for the further incremental evolution of the product.
  • Time-box: a container in time of a maximum duration, potentially a fixed duration. In Scrum all events have a maximum duration only, except for the Sprint itself which has a fixed duration.
  • Velocity: popular indication of the average amount of Product Backlog turned into an Increment of releasable product during a Sprint by a specific (composition of a) Scrum Team. Serves as an aid for the Development Team of the Scrum Team to forecast future Sprints.

I look forward to the Italian version seeing the light of day in 2018. I translated my book (2013) to Dutch in 2016 as “Scrum Wegwijzer“. It was published in German as “Scrum Taschenbuch” (translated by Peter Goetz and Uwe Schirmer) in 2017.

You can still find the Scrum Glossary of those editions on my blog.

Posted on by — 1 Comment

The T-Shape Deception

Every individual is naturally T-shaped. I have never worked with a single person who mastered no more than a single skill only. Every individual I worked with had the (at least intrinsic) capability to perform more than one type of work only. Every individual I worked with had the (at least intrinsic) technical and social capability to join forces with people that master other areas of expertise better and still contribute to that ‘other’ work, learn from it or even acquire it as a new skill.

Ultimately, when people self-organize, i.e. form organized groups without external instructions being imposed on them, around shared challenges and objectives, they unite to form collectively T-shaped eco-systems, entities, teams. The entity as a whole is cross-functional and houses all the disciplines to tackle the complex challenge end-to-end. Within the entity, ultimately cross-fertilization of skills happens.

Every individual is naturally T-shaped. I have also never worked with a single person who mastered every possible skill needed to perform any type of work that might arise when dealing with complex challenges like software and other forms of new product development. The demand for people to be able to do that, is absurd. Yet, it is how the T-shape metaphor is abused. The idea that a cross-functional entity can only be composed of fully cross-functional individuals, in which every single person can pick up every possible task, is absurd.

I find over and over that people are impeded or blocked from employing their intrinsic T-potential rather than being unwilling to do so. Common causes are function descriptions, hierarchy, systems, structures, procedures, instructions, incentives, rewards and other HR processes, enterprise career pressure.

The message that external forces need to mould people into T-shapes is an expression of distrust and disbelief in the potential of people. People are not resources or an assembly of ‘skill’ parts. People don’t need to be deconstructed, disassembled, reconstructed or amended for any preferred shape, like parts forged to fit a pre-empted construction. Systemic impediments need to be removed that prevent people from exploring and discovering their needs and interests, from growing their talents and potential.

Rather than judging people for the expertise they (don’t) demonstrate, focus on creating a context, an environment in which people can unleash their motivation and their multi-skilled potential. Focus on fostering an environment where people can bring in their multi-skills and expertise to leverage a cross-functional and multi-skilled entity (like contributing to T-shaping a team). In the end, complex problems go beyond any individual’s problem-solving capabilities, T-shaped or not. They need T-shaped teams and eco-systems to be an integral part of. And -ultimately- a context in which cross-fertilization happens; people extending their skill sets through peer collaboration and peer learning.

Check in with people about their feeling of valuation. Help them increase their feeling of valuation and unleash their intrinsic motivation. Help them become better at what they do and how they do it. Or, if needed, help them move to a place where they would feel more valued. Help them increase their feeling of valuation.

  • Is the work you are doing right now in your domain of interest? Does it excite you?
  • Do you feel you have the talent and skills to be great at what you do? Can we help you develop your talents and skills?
  • Is the work happening in a (business) domain that makes you feel at home?

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

(Principle #5 from the Agile Manifesto)

The purpose of the Scrum framework is to establish essential boundaries of such an environment of self-organization and intrinsic motivation thriving on the professional drive of people to create excellent products. Scrum frames people’s creativity and intelligence with empiricism. Scrum Master, as a modern manager, is accountable for fostering such an environment of Scrum. A safe environment where people can demonstrate traditionally unsafe behavior, like going beyond the limitations of their function descriptions.

Posted on by — Leave a comment

Creating opportunities to deliver value (as an Independent Scrum Caretaker)

I have wandered the fascinating realms of IT, technology and software development since graduating in 1992, except for the years of running a bookstore (1996-1999). I discovered an Agile way of working through eXtreme Programming and Scrum in 2003. It became my purpose, my belief and my core; spreading the Agile paradigm to help people create better products and humanize their workplace.

After a career as a consultant (2001-2013) and spending 3 years working exclusively at Scrum.org as partner to Ken Schwaber, in 2016 I decided to further my path as an independent Scrum Caretaker; a connector, writer, speaker, humanizer.

I’ve come to accept the difficulty of grasping what this holds. I understand the difficulty when people offer me positions and assignments, assuming I am desperate (for money, status, work). Regardless, through my self-chosen ‘title’ I consider the areas through which to deliver value to the world, to help that world become a better place to live and to work in.

  • “Classes“: Facilitating people’s knowledge and insights in Scrum through Professional Scrum Master and Professional Scrum Product Owner classes, and custom workshops.
  • “Events“: Attending and speaking at events.
  • “Writing“: Creating papers, a new book and blog notes (reproduced at some other channels).
  • “Consulting“: Working with teams and organizations, upon the non-negotiable requirements that it must be personal, about Scrum and serious.

Every activity involves plenty of hours of devising the right words and even many more hours of silent reflection, travelling mental cobblestone labyrinths. I don’t look for money for every single activity in every single service area. Context prevails.

From my standard offer of services:

Through my work I have come to appreciate the uniqueness of every person, team, department and organisation. It has inspired me to move away from fixed approaches. (…) I don’t require specific task descriptions. I require no title. I don’t post my assignments or expose the name of your organisation, unless you explicitly allow or ask me to do so.

Through the initiative of the Scrum Caretakers meetups, I see my experience confirmed that it is not easy being a Scrum Caretaker. It takes quite some intrinsic motivation, belief and dedication (a purpose) to give up (paid) time for mere collaboration on open-ended topics that rarely serve a commercial purpose. It did get me in touch with a lot of non-usuals suspects, outside of the threaded paths of ‘Agile’. The sheer beauty of that experience makes up for a lot of the sacrifices.

I am gratified for the opportunities I stumbled into through my years at work. It served me well in becoming what I didn’t know I wanted (or was able) to be. Most dots only got connected in retrospect, still making it seem as if there was a plan. There wasn’t. In general I had no clue. I still haven’t. But becoming an independent Scrum Caretaker did help me shift towards creating opportunities to deliver value, and help more people deliver value. Reciprocity.

Posted on by — 3 Comments

Inside of the whirlwind (The third Scrum Wave)

Scrum is a simple framework that supports people in making the most of complex challenges. Organizations are re-discovering the sophisticated simplicity of Scrum. The third Scrum Wave is rising. Will you sink? Swim? Or will you surf? Shape the wave, shape the future?

TALC – the Technology Adoption Lifecycle

The Technology Adoption Lifecycle (TALC) describes the adoption stages of technology products or services, disruptions and discontinuities in hi-tech innovation. The TALC was created by Geoffrey Moore as an expanded version of the adoption cycle of more traditional products and product lines. Every stage has typical adopter types.

Moore added a “Chasm” period after the phase of Early Market. It is a period of stagnation, a period where adoption stalls. Some unknown time passes by before the next phase of adoption is entered, the Bowling Alley. The Chasm is unpredictable in length, but also in outcome. Some products never get out of this stand-still and simply disappear.

AALC – the Agile Adoption Lifecycle

The term ‘Agile’ became part of the software development lingo in 2001 with the publication of the Agile Manifesto. Before that time, it was just a plain English word that -in short- is synonymous to ‘adaptive’. In a way, it still is.

New technological products that follow the Technology Adoption Lifecycle could be developed applying Agile techniques and principles. Agile in itself however is also a new, and clearly disruptive, game on the technology market and is therefore subject to the Technology Adoption Lifecycle as well.

2001 marks the start of the Early Market phase. At this stage Agile was mainly recognized and promoted for its potential value by early adopters; pioneers, visionaries, enthusiasts, innovators. Early adopters included individuals, teams and organizations.

During the preceding ‘avant la lettre’ phase several approaches and techniques that later became ‘Agile’ were being explored by various ‘creators’. Important milestones are 1995 and 1996, the genesis of Scrum and eXtreme Programming. They were 2 well-defined new approaches to software development in which many of the core ideas of what became ‘Agile’ can already be discerned.

A much broader audience discovered Agile as from 2005-2006. For many organizations the traditional way of working, the industrial paradigm, had been stretched far beyond its limits. There was nothing to stretch anymore. It created mental openness for a very different paradigm. Early Pragmatists discovered the advantages of the new paradigm, of ‘Agile’, and believed its problem-solving capabilities to exceed those of the existing ways. They were looking for solutions that might work. They had no need for widely documented evidence, but settled for the growing amount of anecdotal evidence. Agile crossed the chasm.

Although the TALC typically describes the succession of the Bowling Alley and Tornado adoption phases, the post-Chasm years of Agile primarily showed many back-and-forth movements. There was a lot of pull-back from the traditional, industrial paradigm. Still, a viable market formed.

It is probably too soon to distinguish the Bowling Alley from the Tornado yet. I mainly observe a strong whirlwind that Agile goes through.

Inside of the whirlwind – The 3 Scrum Waves

Regardless the inability to distinguish the transition from Bowling Alley into Tornado at the current point in history already, Scrum has been the dominant definition of Agile post-Chasm. Scrum is the gorilla that emerged.

Inside of the whirlwind, three waves of Scrum have manifested.

The first wave of Scrum, rising with Agile crossing the chasm in 2005-2006, was a reconnaissance wave for many. Organizations faced obvious problems in the IT and software delivery domain that could no longer be patched through the industrial ways. Scrum was adopted as the new IT development process.

The second wave of Scrum built on the first wave when in 2010-2011 large organizations -often in the aftermath of the financial crisis- discovered they were at the end of the old ways of working too. In the slipstream of this ‘success’, sub-groups and derivative movements took off, new movements and methods were invented, introduced, launched, and often disbanded again. Divergence and scale were the ruling themes, on top of the common use of Scrum’s terminology and the shared desire to deliver working software in Sprints.

The third Scrum Wave (2016-2017) is fuelled by the desire, the drive for rhythm, focus and simplicity. Too much organizational waste, neglect of people and embedded complexity remain, fundamental impediments unresolved by the (often complex) solutions of the second wave. Organizations renew their acquaintance with Scrum. They appreciate that it is a well-defined and clearly stated framework that creates room for diversity, in it that Scrum can wrap a variety of strategies and techniques to be employed.

Convergence appears on the horizon, where the rage of scattering, where the whirlwind might start calming down. Agile professionals worldwide sow seeds, and fertilize the grounds for many organizations to start bearing fruits, to start enacting Scrum. Join the bigger movement.

 

Posted on by — Leave a comment

Closed-loop feedback control with Scrum

Scrum is a simple framework to manage complex challenges. Software delivery is a complex challenge. Software delivery encompasses a multitude of complex activities to create and evolve complex products in complex circumstances. Scrum embraces and emphasizes the complexity of software delivery by implementing the only process type that fits its complexity, empirical process control.

Complexity

There are many variables that have an impact on delivering software; requirements, skills, experience, people, teams, technology, integrations, market conditions, company strategies, budgets, regulations and dependencies, to name just a few. Not all known variables are controlled by the people doing the work, although they have to incorporate the impact on the work. For some known variables too much detail is needed to fully comprehend them. Even if a variable is known, its behavior -now or in the future- may be unknown, or different from what is anticipated.

Products are created by people with cognitive capacities. People are not robots, or replaceable pieces of machinery. The outcomes are hard to describe in an exact and detailed way; before, at the beginning or even as the work advances. Every product created is unique and what is appreciated can only be established when released. The activities to be undertaken aren’t predictable with any degree of high precision. They have not been performed before, in the same way, under the same conditions, several times. The environment evolves constantly. And, most annoying, not all variables are known. There is a high degree of unpredictability.

The degree of dynamism of a challenge requires the right process to be in place in order to have control:

Open-loop systems

An open-loop system is designed for execution of a series of preempted steps to result in a defined outcome in a single run. Such a system assumes a near-perfect predictability of the variables that influence the process as well as of the process activities themselves.

For larger problems, typically a chain of open-loop subsystems is created. The output of a subsystem is the input to the next subsystem. Although theoretically risks should be confined to the smaller subsystems, in practice the whole system’s vulnerability increases exponentially. In situations of turbulence and change, deviations and variances accumulate across the various subsystems, e.g. in timing and quality. It is not uncommon for the accumulated problems to surface only at the end of the final subsystem.

Predictive plans and hand-overs of work between separate functional groups are implementations of open-loop thinking. Predictive plans can only include known variables, their known details and their anticipated behavior, creating the illusion that no unknowns exist. Open-loop thinking invites lengthy upfront consideration of all elements of the plan, and ultimately attempt to foresee the unforeseeable.

An open-loop system is -by design- unable to cope with the amount of disruptions and unknowns typical for complex challenges like software delivery.

Closed-loop systems

Closed-loop systems implement frequent opportunities for inspection so adaptations can be implemented. The actual outcome of the system is compared in a timely fashion against a desired outcome. Desires may change. Variances or undesired results are eliminated or corrected in the next or in future runs. Not all variables and parameters need to be known precisely and in detail, as the process is self-correcting. The system requires and creates transparency. Reality is inspected, and exposed, so that appropriate adaptations are undertaken. The people performing the inspections have clear and agreed standards in place to inspect-and-adapt against. Inspection for reporting and status purposes is pointless. Inspection without adaptation is pointless.

Closed-loop feedback control with Scrum

Scrum embraces and stresses the complexity of software delivery by implementing empirical process control. Scrum replaces the open loops of traditional, phase-gate, staged or similar processes with closed-loop feedback. Scrum defines regular opportunities to inspect and adapt. Scrum enables players to halt the traditional rat race. The players are enabled to stop, reflect, learn from inspections, gather feedback over the output and change course, re-organize, update priorities, improve, adapt. Scrum brings reality back in the game. Scrum brings transparency. That is pleasant when all is progressing well. That is crucial when all is not progressing as hoped for. It allows re-positioning and correction.

In Scrum all work is organised in Sprints. Sprints are time-boxed to assure timely inspection and adaptation. A Sprint forms an ‘inspect and adapt’ cycle of a few weeks at most that wraps the 24-hours ‘inspect and adapt’ cycle of the Daily Scrum:

  • At the Daily Scrum the people doing the work inspect their progress, and identify their most important work to do next within the container of the Sprint. They use the Sprint Backlog, the Sprint Goal and a progress visualization to self-organize within the Sprint. The daily cadence assures they never get out of sync for more than 24 hours.
  • A Sprint is a cycle that starts with identifying and interiorizing the most important ideas instantiated on Product Backlog. Sprints end with an inspection of the product Increment that was actually released or could be released, as well as how it was built, the process, the interactions, the technology at play. As with all inspections, they are forward-looking. They serve the purpose of adapting.

All events of Scrum set a frequency for the inspection and adaptation process, where the artifacts contain the information to be inspected and adapted. Scrum describes the accountabilities needed to perform the inspections and adaptations.

Organizing work in Sprints allows people to take a breath, to break with the traditional rat races, and work at a sustainable pace. Explicit reflection moments are introduced that are crucial for humans to thrive in cognitive, creative work of high complexity, like software delivery is. Within a Sprint, additional feedback loops are created, e.g. through agreed work and development standards.

Note: above text is adapted from my book “Scrum – A Pocket Guide (A smart travel companion)”. If you have more time to spend, consider reading it.

Posted on by — Leave a comment

Re-vers-ify (re-imagine your Scrum to re-vers-ify your organization)

Agility is why organizations adopt Scrum.

Organizations suffer as they fail to act with agility through product releases, on the market, for users and consumers, facing competitors. Scrum is mandated and it is overlooked that the agility demonstrated outwardly also depends on the setup of internal structures.

Organisational rigidity is the result when people are separated in functional silos, when collaboration is instructed through hand-overs and governance, when go-see management is not practiced, when the daily work has no room for discontinuous innovation. Basically, such rigidity is the anti-thesis of Agile and impedes outward agility.

Scrum is a simple framework for complex product delivery. Scrum thrives on the self-organizing capabilities of collaboractive people creating finished versions of product in short cycles, called Sprints. Scrum is in itself agnostic of internal structures, positions, titles, hierarchies. Scrum has no mandatory rules for organisational constructs. Scrum is simple, not easy. The simple rules and roles of Scrum are most often twisted and broken to fit an existing organization. Yet, it is nearly impossible to benefit really from adopting Scrum without updating the internal operating systems.

The sensible and courageous way forward is to re-vers-ify, to re-imagine your Scrum to re-emerge your organization. It is a path, not the destination. The destination, an updated organization, is unknown, remains to be discovered.

  • Use Product Backlog as the single plan for one (1) meaningful initiative (project/product/service). Slice the initiative if it is too big.
  • Reset the accountabilities for the selected initiative to Product Owner, Scrum Master and Development Team(s).
  • Facilitate the eco-system with tools, infrastructure and a (Scrum) team zone in order for them to create sashimi releases. A controlled and automated deployment pipeline is certainly a much needed step forward.
  • Repeat, grow, learn, expand.

“Re-vers-ify” is a narrative to help people re-invent their organizations; an invitation for people to re-imagine their Scrum to re-vers-ify their organization. Over the course of 2017 I have introduced re-vers-ify in several ways. I have now highlighted the essence in a short movie. It takes only slightly over 3 minutes of your time. Enjoy!

If you have more time to spend, consider reading my book “Scrum – A Pocket Guide (A smart travel companion)“. It ends with following belief:

Posted on by — 1 Comment

Product Backlog and the tea leaves effect (a message to Product Owners)

Product Backlog is a strategic instrument of high value; for stakeholders, product management, the organization, the Development Team(s), and the Product Owner. When employed well, Product Backlog reflects the vision, ambitions, roadmap, needs and wants for a product or a service, all in one place. Imagine how your competitors would love to have access to it!

Product Backlog has the potential, as a single artefact, to replace a multitude of other predictive plans and traditional documents. In Scrum, Product Backlog is all the plan you need. For Product Backlog to enhance simplicity and transparency, Product Owners maintain Product Backlog continuously. The Product Owner, actually owning the product, orders and manages it to reflect the actual needs, wants and ambitions.

Product Owners likely apply multiple hands-on strategies to keep Product Backlog tidy and accurate. It helps for many Product Owners to realize how the tea leaves on a Product Backlog impact transparency.

Having explained Product Backlog and the Tea Leaves Effect in the past, I have now summarized it in a short movie. It takes less than 2 minutes of your time. Enjoy!

Posted on by — Leave a comment

Blog Statistics (country views)

On Valentine’s Day of 2008 I started my blog “Ullizee.wordpress.com” with a first blog post. The URL still exists but is now redirected to “guntherverheyen.com”.

Since that day I have created 457 posts. The past years I blogged primarily about Scrum, and rather occasionally still about my love for books, music and my family.

I am mostly amazed by the global reach of my musings. The statistics show that my blog was visited by people from 182 countries. The top 10 countries (5,5%) account for 75% of all traffic.

Another 20% of all traffic is by visitors from an additional 30 countries (16,5%). So, 95% of all traffic on my site is generated by visitors from 40 countries, i.e. 22% of all countries. That leaves 142 countries, 78% of all countries, accounting for the remaining 5% of traffic.

Hereby a huge thanks and a big hug to my international readers, followers, likers, sharers. You mean the world to me.

Love
Gunther.

Posted on by — 46 Comments

Scrum. Period.

I observe a revived interest in Scrum. I observe how people, teams and organizations re-discover Scrum. Scrum has the simplicity they grasp for. They see the value Scrum brings. Simple and valuable, not easy. In a forward-looking observation I described it as the third Scrum wave that is rising.

Scrum is simple indeed, yet has so many aspects to be discovered by so many organizations. Scrum serves a journey of product discovery. Adopting Scrum is a journey of discovery in itself.

Scrum is a simple, yet sufficient framework for complex product delivery, for managing complex challenges. There is a high cohesion in the minimalist set of rules and advised activities of Scrum. There is no such thing as individual Scrum practices. Scrum lays down essential boundaries within which people self-organize, within which people devise a way of working tuned to their own context. Scrum can wrap many practices. When applied well, the integral result is still… Scrum.

The themes of the recent past of Scrum were ‘scale’ (volume) and ‘divergence’ (different names and movements). Distractions. People, teams and organizations realize that it did not result in the agility they need in their complex context. I observe a revived interest in the cohesion of Scrum, the framework as a whole. People, teams and organizations learn that over-focusing on isolated elements of Scrum has not helped them tackle their complex challenges and humanize their workplace.

While rediscovering Scrum, as a whole, people, teams and organizations discover that Scrum still leaves plenty of room for their context-specific needs. Scrum is designed to holistically support people, teams and organizations to create, maintain and sustain complex products. Scrum does not replace people’s intelligence and creativity, rather provides a frame for people to operate within and create valuable results. Scrum is intentionally low prescriptive. Scrum offers a limited set of mandatory prescriptions, which in turn allow many variations to apply the rules.

Scrum most often does not fit the existing, rigid structures of many organizations, the hidden impediment to achieve true agility. Stick with Scrum. Consider the core framework to be immutable. Period. Start small. Through practice all people involved will ingrain new behavior, enact the Scrum Values and grow a new working culture, a more humanized workplace.

Twisting Scrum, hacking into the basics of the framework breaks its cohesion, covering up dysfunctions rather than revealing them, probably disregarding the principles and foundations upon which Scrum is founded, rather than promoting great behavior. Such versions and implementations are possible. Isolated use of Scrum’s terminology or individual elements is possible. They might look like fun. They might work. They lack cohesion. They are not Scrum.

The 3rd Scrum wave is rising. Will you sink? Will you swim? Be a laggard of the second wave? Or will you surf?

On a personal note I want to add that I am delighted to see a shift from ‘Agile Coach’ to… Scrum Master. A good sign. A sign also that the need is real to have someone working with the teams and with the organization in fostering a healthy environment, an environment where innovation and creativity can emerge, where people can demonstrate traditionally unsafe behavior.

Posted on by — 2 Comments

Product Owner, actually owns the product

The description of a Product Owner’s work reads as no existing job summary. “Product Owner” is not just a new name for the old roles and titles originating in the industrial beliefs that dominated businesses and society far too long.

Our dependence on software and technology keeps accelerating. We live and work not only in a globalized but also in a digitized age where technology, knowledge and the availability of information prevail more than ever, through a variety of technology products more than ever. Product Owner is a new, modern role, that fits that new world.

Product Owner, within an organization, actually owns the product, is a product-CEO. Product Owner is the many-faceted servant-leader in an eco-system revolving around the product, an eco-system that stretches beyond the borders of the organisation that creates the product. Product Owner is a strategic role, that is still ignored too much.