As I was working on the second edition of my pocket guide to Scrum in 2018, Rodrigo Silva Pinto and Leonardo Bittencourt proposed to create a Portuguese translation of my book. It was the start of a collaborative endeavour towards self-publishing the translation.
I am humbled and honoured for announcing that the result is now available as “Scrum – Um Guia de Bolso (Um companheiro de viagem inteligente)“, in Kindle and in paperback format via Amazon.
(note: the primary market for the Kindle version is Brazil which allows me to keep the price affordable. The paperback’s primary market could not be set to the same so I had to set that to the US. Both versions however are available through all market places of Amazon.)
I wish all Portuguese speaking friends of Scrum much joy reading my translated thoughts, beliefs and considerations of Scrum, that simple framework to address complex challenges. I feel forever indebted to Rodrigo and Leonardo for making my book available for all Portuguese readers, and to Barbara Knijff of Jellylab for creating the cover.
Here is how Rodrigo and Leonardo introduced their work in the book:
Rodrigo Silva Pinto, Agile School, junho 2019
Tenho a oportunidade de formar centenas de pessoas todos os anos em treinamentos de Scrum que vão dos fundamentos a conteúdos mais avançados. Um pedido comum entre os alunos é a indicação de literatura do gênero. Mas a resposta por muito tempo era não satisfatória: “O livro Pocket Guide do Gunther é o melhor, mas só está disponível na língua inglesa”. Havia uma lacuna, faltava uma boa referência literária do Scrum para os falantes de língua portuguesa.
Cansado de esperar, resolvi fazer parte deste projeto, propagando um conteúdo de altíssimo nível e me associando a um dos autores mais influentes do tema, depois dos próprios criadores do framework.
Espero que as horas dispendidas em “Scrum – Um guia de bolso”, possam contribuir com a comunidade Ágil e o mercado brasileiro para juntos construirmos produtos com alto índice de profissionalismo e que gerem impacto necessário para mudar o mundo.
Leonardo Bittencourt, Principal Lean/Agile Consultant, junho 2019
Tive o prazer de conhecer o Gunther pessoalmente durante Agile Tour Vilnius em 2017. Posteriormente colaborei com a tradução de dois de seus trabalhos para Português, o Glossário Scrum e os Valores do Scrum. Indubitavelmente ele faz juz ao que se auto-intitula, Zelador do Scrum (Scrum Caretaker).
Nesta obra, Gunther usa uma linguagem simples que vai direto ao cerne do Scrum, aborda os pontos cruciais e clarifica o framework Scrum de uma forma cirúrgica. Este livro lhe ajudará a evitar armadilhas, equívocos e adoção de um Scrum mecânico. Você compreenderá o propósito do Scrum Framework bem como os porquês de cada elemento que o compõe.
Manter o conteúdo sem distorções e com a mesma clareza, onde as palavras usadas na versão original foram minuciosamente pensadas, trouxe uma boa dose de desafio extra.
Indico este livro para quem está iniciando e para quem já tem experiência com Scrum. Lhe garanto que durante sua leitura – ou releituras como no meu caso – sempre haverão novas descobertas.
I have been employed by different enterprises, large and small. I never had the ambition to be a wild duck 🦆, though I typically ended up being seen, treated and described as one anyhow. How strange as I am someone who habitually avoids rather than looks for conflict. How strange to always end up being the person that the powers that be would love to hate, but can’t get beyond ignoring. It is hardly comforting that most instances only get to the stage of tolerating me while ignoring me.
There is no having friends for those not having enemies.
Wild ducks are “bad for business,” say the powers that be, enthusiastically supported by the business suits, the career hunters, the position addicts. Yet, every time I decided to leave an enterprise the drama couldn’t have been bigger. How strange that it was even worse “for business” that I would leave. Honestly, the expected disasters never actually materialized. No company ever went out of business over this maverick duck flying off.
Although I know a few people that prefer calling me a Scrum panda 🐼, wilfully choosing the path of independent Scrum Caretaker ultimately lead to me feeling more like a butterfly 🦋 today. Like a butterfly, I flap my wings. I observe, I create, I connect, I share. Like a butterfly flapping its wings I do it because it is in my nature, not because I envision specific consequences, big or small, or set goals or targets, hard or soft. Most consequences are inherently unpredictable anyhow.
More than often I see how my ideas get used and re-used without consultation, citing or other forms of attribution. I am flabbergasted by it. Likely unintended (people not thinking twice), but there is a smell of disrespect. Much worse is it when my ideas are altered, turned simplistic, changed into stereotypes, their sfumato masked and concealed in black and white boxes, when concepts are twisted, cut up, even butchered. That is… theft. No words can describe my emotions over this.
Regardless the lost art of attribution and the hurt it causes, I keep flapping my wings. Observing, creating, connecting, and sharing is in my nature. It makes no sense for a butterfly to stop flapping (or even try to). I’m not sure how that is for a wild duck.
It took time to realize, accept and embrace that most things take time, especially creating who you are. Is the tortoise 🐢 in me gradually taking control?
The toughest fight in life in the end is the fight of not having to turn bitter.
In complex and uncertain environments, more is unknown than is known. There is much we don’t know. What we know is subject to change. Only what we have achieved is known (unless we prefer to cover up). Progress is in what we have done, more than in what we plan to do. What we plan to do are assumptions that need validation by emerging actions and decisions. We make and incrementally change decisions based on what is known.
In Scrum it is considered a good idea for teams to know about the progress they have been making. It is one parameter (of several) to take into account when considering the inherently uncertain future.
The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team.
Teams express this Scrum Guide guidance of ‘past performance’ often as ‘Velocity’. Although not a mandatory concept, it is a good tactic to apply in Scrum and for many teams even useful to increase their proficiency in self-management.
Painful problems arise however if Scrum gets managed through the distorting lens of the old, industrial paradigm. Purpose gets lost and ideas get corrupted. No more than an illusion of agility is created. One such case is when Velocity becomes an indicator of volume (of tasks and features produced) and is measured for external justification (i.e. beyond the team boundaries).
Although Scrum can be employed to address any complex challenge, Scrum is foremost applied as a framework for complex product delivery. For many organizations the availability and usage of their products and services is life-critical. They adopt Scrum because they need to act with more agility against that life-critical purpose. Scrum is designed to deliver agility to these organizations under the form of releasable versions of products, called Increments. The purpose is to enable organizations in having an effective impact on the market place no later than by the end of each Sprint. This is a crucial trait of agility for organizations that are highly product or service-dependent.
Against that purpose it is not helpful to not have a releasable product version by the end of a Sprint. We allow even what we have done to remain full of unknowns. We undermine the only base we have for making decisions. We undermine the solidity of our already fragile decision process even more. In terms of real progress, Velocity is actually… zero.
In the face of the purpose of increased agility through Scrum, it doesn’t add much value to discuss Velocity at Sprint Review when no releasable Increment has been created throughout the Sprint. There are probably more serious problems to address first. There are more important challenges than measuring how many points were burned. Let alone the completely futile attempts to standardize, normalize, industrialize, or equalize Velocity across an organization.
In the absence of teams’ capability to effectively produce releasable Increments, such discussions do no more than distract from the more serious problems. Velocity becomes an obfuscating indicator. The definition of Done provides the real transparency for inspection and adaptation. The definition of Done shows what is lacking to increase product quality up to the point of Increments being releasable. In the face of the urgency of agility, the question of what is defined as Done is much more important than registering the amount of unreleasable work produced.
You can obviously measure the Velocity at which undone work is created, and be more predictable in creating even more undone work. It will not help you make progress towards increased agility and having an impact.
Rather, at the Sprint Review ask yourself “What is our impact on the market? What is our ability to go to market?” It will steer the conversation in very different directions than merely reporting how much tasks were completed. Take the findings to your Sprint Retrospective to figure out what is needed to improve on the possibility to go to market next Sprint. Have the ambition of going through an engaged retrospective, rather than one of unfocused fun. Aspire to start creating valuable Increments with a demonstrable impact, no later than by the end of your next Sprint. Nobody external to the team will care about your Velocity, as an external indicator of progress, anymore.
In the face of the purpose of increased agility through Scrum, Velocity, actually, only makes sense if a measure of a team’s capability to create releasable Increments of product, no later than by the end of a Sprint.
The 2019 edition of Scrum Day India is happening on Saturday 20 July 2019, in Gurgaon (Delhi NCR).
Sanjay Saini, owner of Agile WOW (“Agile Ways of Working”), kindly invited me, as an independent Scrum Caretaker, to open and close the event. I hope many Scrum practitioners register at scrumdayindia.org and join the event. In the end, only eager attendants can turn events into insightful experiences!
Sanjay and I agreed on the theme for the 2019 edition of Scrum Day India to be “Beyond Deceptive Agility“.
Many organizations embark on an Agile journey, a journey to increase their agility. We find that the result is often quite deceptive, in terms of business outcomes as well as to the teams, leaders and user bases of these organizations. As we inspect to adapt in Scrum, we want to explicitly move beyond merely detecting this unfortunate situation. We hope to share some insights and stories about moving beyond deceptive agility.
As a personal note I want to add that I am not just excited for visiting India for the first time ever. I see my visit as a way to express my support not only to the Scrum practitioners in India, but also to local experts. Beyond helping organizations in their adoption of Scrum, Sanjay is a Professional Scrum Trainer, licensed by Scrum.org to teach Professional Scrum classes. Check out all Professional Scrum classes in India!
Many of today’s enterprises are hardly fit to play a leading role in today’s world. They are designed on the past-world premises of stability and high predictability, of repetitive work with easily scalable results. They experience profound difficulties having to navigate the predominantly uncertain and unpredictable seas of today’s world. An increase in agility is needed. They adopt Scrum. Rather than updating their past-world structures while introducing Scrum, they twist Scrum to fit their currentorganization. No more than an illusion of agility is created as a result.
Imagine they would re-imagine their Scrum and re-emerge their organization to firm up their agility…
Organizations, certainly if they have been around for a while, grew into very complicated and extremely interdependent internal structures. These structures are often the root of the problems organizations seek to resolve by adopting Scrum. Work is essentially seen and organized as assembly line work. Many bodies, meetings, hand-overs, resources, deliverables, processes and departments are required to produce and deliver even the smallest chunks of work.
Organizations naturally revert to familiar recipes when facing the need to become more Agile, including mass-production and cascaded approaches, separate transformation projects, copy-pasting what other organizations do or blindly following blueprint prescriptive models.
Individuals are grouped into ‘teams’. The teams are ‘coached’ into complying with standard sets of practices and processes, unified Sprint lengths and electronic process tools. This is uniformly done across the whole organization, regardless business domain, expertise or technology at play.
The existing organizational constructs are not touched, or touching them is cleverly obstructed, if not sabotaged. Teams (often micro-sized) are typically established within existing departments or other forms of functional separations. Higher-up optimizations, like synergies across teams and departments, are ignored in the same way they were before. The systemic disconnectedness that used to inhibit collaborative problem solving between individuals now inhibits collaborative problem solving between micro teams.
More Agile teams does not make a more Agile organization.
Practitioners worldwide turned Scrum into the most applied definition of Agile. Despite Scrum being the new reality, most organizations continue struggling with Scrum. They struggle as they think teams can be constructed. They struggle as they try to map Scrum’s accountabilities on existing functions. They struggle to understand that inspection without adaptation is pointless in Scrum. They struggle to understand how Scrum can wrap a variety of practices, allowing each expression of Scrum to be tuned to a specific context without fundamentally altering the framework. They struggle to re-invent their organization around Scrum to inject agility in their internal structures, although this will ultimately be reflected in their business outcomes. Organizations lack the imagination to picture how Scrum can work for them, mentally blocked to think beyond their current set-up.
Can you imagine Scrum being employed as designed and intended, regardless your current organization? Do you have the will to deeply reflect? Go back to the ‘why’ of your Scrum? Face your clear and apparent urgency? And take action? Recover, reboot, re-imagine?
In order to firm up their agility, courageous seekers re-imagine their Scrum to start re-emerging their organization. They leave behind past attempts, choices and approaches (all that didn’t work). Over-ambition, magnitude anxiety and deflation angst are mitigated by downsizing to small again and subsequently growing iterative-incrementally. They go through incredibly hard work when they:
1/ Re-consider what the ‘product’ is for the implementation of Scrum (or select another clearly bounded and meaningful initiative). Slicing the initiative if it is too BIG.
2/ Re-imagine Scrum for the selected product/initiative/slice.
Use Product Backlog as the single plan, holding all development work, whether technical, functional or non-functional. Establish what it means for product Increments to be releasable.
Reset the accountabilities to Product Owner, Scrum Master(s) and Development Team(s), full-time dedicated to the initiative and optimizing for the whole rather than for titles, positions and utilization. The eco-system, this newly established Scrum zone, is facilitated with tools, infrastructure and space.
3/ Create coherent, small and tasteful sashimi releases, no later than by the end of each Sprint, through a controlled and automated deployment pipeline.
Courageous seekers take a few Sprints before expanding to a next product/initiative while still improving the existing initiative(s) and relentlessly removing all impediments to the envisioned state of product delivery. Is an environment in place where people are willing to demonstrate the undiluted accountabilities of Scrum? Are teams self-organizing toward delivering releasable Increments providing start-to-finish value, no later than by the end of a Sprint? Are the teams fully equiped with all skills needed, a dedicated team space, all tools, infrastructure and authorizations?
It takes quite some persistence and belief to keep fighting the past-world tendency to control individuals. Remind yourself (or welcome others reminding you) that value is in the outcome of the work, not in the volume produced. At the Sprint Reviews, consider the value a team has potentially created in a Sprint, and align with them on what seems most valuable to work on next. Move away from judging individuals for their hours spent on individual tasks. Team Engagement is the key.
People who are engaged actually care a lot more about customer outcomes and profitability.
Continue re-thinking your internal constructions as initiatives grow, new initiatives spin up and start delivering value. Solve further organizational issues and inadequate policies as you run into them. Start re-emerging the organization upon conscious acts of re-imagining Scrum; funding, HR policies, rewards and incentives, governance, quality assurance, sales and marketing, legal and regulatory compliance. Unleash a way of working that will sometimes lead you to quite unpredictable destinies.
It is hard work. It is a path of learning, experimenting, falling and getting back up. It is transforming how you work, not adding work and complexity to what you already do. It is gradually re-merging your organization towards a networked system of self-sustaining product hubs. A product hub grows or shrinks as needed (following product ambitions and market needs). A product hub is added or disappears as needed (when spinning up or exiting a product). Embed the empirical approach of inspection and adaptation in your managerial practice and in your organizational set-up.
In 2013 I accidentally created a book, “Scrum – A Pocket Guide” (subtitled: A Smart Travel Companion). Creating my book, accidentally or otherwise, had many unanticipated (mostly positive) consequences, for which I am very grateful.
In 2018 I deliberately evolved my Scrum travel companion into a second edition (available 2019). This second edition of “Scrum – A Pocket Guide” is available worldwide in all major formats via diverse channels:
“Players And Accountabilities In The Game Of Scrum” is an audio excerpt from that second, updated edition. The excerpt covers chapter 2.5 (introduction) and chapter 2.5.1 (pages 49-52) and can be listened to at Soundcloud.
I originally described the Scrum Values in English as part of the first edition of my (accidentally created) book “Scrum – A Pocket Guide” (2013). I updated the text slightly for the second edition (a deliberate evolution) of my book (2019). The Scrum Values were added to the Scrum Guide in 2016. The English version was translated to the international versions offered in this document for you through several iterations that started early in 2018.
I cannot express my gratitude enough to following people for spending the hard work of making the international versions of the Scrum Values available for you:
Arabic: Rasheed Raya
Chinese (simp/trad): Lana Sun, Wei Lun Teh, Chee-Hong Hsia