Make your Scrum outcome-driven!
Do we spend too much time deciphering the theory of Scrum? Could we achieve more talking about user outcomes and business impacts? In the second edition of Scrumday Barcelona we want to bring new ideas and solutions on a keynote track learning from the experts and also working together on an interactive track!
Virtual event: December 2nd
The event will start in
This event of one day is made of two parallel tracks:
- Fun: Let’s learn while having a good time!
- Safety: All people and their opinions are respected and welcome.
- Affordable and open: Low prices just to cover costs. Sessios in English and Spanish.
- Solidarity: All profits will be donated to improve the life of MS patients.
The sessions will be recorded and made available to attendees.
Author of User Story Mapping
Jeff makes use of over 20 years of product design and development experience to help companies create great products.
Author of Dynamic Reteaming
Heidi Helfand is author of the book Dynamic Reteaming. She coaches software development teams using practical, people-focused techniques, with the goal of building resilient organizations as they double and triple in size. Heidi is currently VP of Engineering Growth at Kin Insurance.
Co-author, Team Topologies
Manuel Pais is co-author of the book “Team Topologies: organizing business and technology teams for fast flow”. Started the Team Topologies Academy to help organizations scale learning around modern team dynamics and fast flow.
Author Lean UX, Sense & Respond
Jeff Gothelf is the autor of Lean UX, Sense&Respond and Forever Employable, and co-CEO of Sense & Respond Press. He also works as a coach, speaker, author & consultant to help organizations build better products and executives build the cultures that build better products.
Professional Knowledge Sharer
Currently I am working as an Agile trainer at Xebia Academy, where I fully focus on sharing knowledge; teaching, conferences, developing and improving of trainings and trainers. I am also certified to teach the ‘Training From the Back of the Room’ and co-created the Virtual Edition of it with Sharon Bowman.
Working with teams to help them work better.
I’m interested in the human side of building an high performance agile or lean organisational culture. Experienced (servant) leader, professional coach, Professional Scrum Master, and strategic systems thinker.
Business Agility | Strategic advisor
As a Business Agility Executive Coach and Strategic Advisor, for more than 10 years, I had the opportunity to participate and lead multiple international transformations from big companies in more than 14 countries and very diverse cultures.
Conecta y colabora
Organizations that do not adapt rapidly to the modern, highly-changeable business and technical environment are failing, and failing in large numbers. Increased regulation, pressures from climate change, shifting of energy sources, digitalization, cloud-native, and (recently) the COVID-19 pandemic are all driving a need for business and technical agility in organizations of all sizes.
In this talk, we’ll explore how the patterns and principles from Team Topologies promote true business and technical agility through a rapid flow of software change, fast feedback from running systems, a strong drive for loose coupling, and an awareness of sociotechnical mirroring. Combined with a product mindset and techniques from Domain-driven Design, the Team Topologies approach is helping organizations around the world to adapt to the “new normal” and achieve true business and technical agility.
My professional background is originally in a high-risk industry. When you are drilling for oil in a new area, the success rate is about one in ten. With an average well costing anywhere between $20 to $200m, billions are spent each year on failed projects. On top of that, there’s risk to health, safety and the environment. Complex engineering and huge pressures underground can lead to disasters with a high cost in human life and to the environment. My background is also in IT; to image the subsurface we need Tbytes of data, tens of thousands of compute hours, and to optimize the flow of work across human and physical constraints. When I started work we were in self-organising teams with a Kanban board to shape the flow, and a focus on those constraints. None of knew about lean, agile or ToC, it was just “how we did things round here.”
I’m going to talk about how what I learned in one of these worlds has influenced my thinking in the other. That’s got a lot to do with human error, how our brains work, and how we can move towards better outcomes.
Nassim Nicholas Taleb first coined the term “black swan event.” In Europe, all swans were white until people visited the southern hemisphere and saw black swans. It’s used to describe an unanticipated event, which with hindsight, seems obvious.
IT projects suffer from black swan events. There’s a great HBR paper by Bent Flyvbjerg and Alexander Budzier that explores this. The title was “Why Your IT Project May Be Riskier Than You Think” and starts off with Levi-Straus budgeting for $5m to upgrade their Enterprise Resource Planning software and spending $192.5m, and almost taking out an iconic brand in the process.
All major disasters tend to be black swans. A sequence of small changes at a low level invisibly increase the risk; people lose sight of the systemic picture, and how close to failure they have become.
In 1980, a drilling platform called the Alexander L. Kielland collapsed in the North Sea, killing 123 people. Subsequent analysis showed that the installation of a hydrophone in one of the legs
- ironically to increase safety of diving operations
- had led to structural failure of that leg. The rig design was systemically flawed as a result of a small design change.
So why do big things fail?
My simple answer is human error. With William Royce’s 1970 paper on Managing the Development of Large Software Systems we can unpack a bit why that tended to happen in large scale IT projects.
The slightly deeper answer relates to fear and organizational culture. Patrick Hudson and Ron Westrum’s work on safety culture, points to how people can be afraid to talk about risk. The work of W Edwards Deming and Amy Edmondson comes to the same conclusions, from a different direction. Forsgren, Humble and Kim suggest the same findings in their work on DevOps.
An even deeper answer relates to empiricism and the scientific method. We talk about these things pretty glibly in agile circles, without really unpacking how those things should work to prevent defects.
There’s two core risks we need to explore in software development:
- we might build the wrong thing
- we might build the thing wrong
From an agile and scrum perspective we can add a third risk
- we might fail to improve
Once we recognize the role that human error plays in our thinking, we can start to bring that into our understanding of agility and Scrum. Where a waterfall development process has the fundamental assumption that “we are right” about our analysis, design, execution, testing and deployment, an agile approach needs to embrace the idea that we might be wrong.
While some people contend that being agile is enough to manage risk, I think that exploring what we can learn from human error, and why experts can be “strong but wrong” can help us to be better at what we do. That means designing our way of working for fallible humans, and making sure to quote Michael Küster’s excellent blog – we fail quickly, fail cheaply, learn and move on.
To get the most out of the Scrum Events I tried a lot of things. I experimented with formats and setups. Did a Facilitator training and looked for interesting games and Sprint Retrospective formats. But I never looked further than that. Until I did the Training From the Back of The Room and was intrigued by how the brain works in a training and learning setting.
Learning more about the human brain I figured out one could also use Brain Science to keep the Scrum Events alive and worthwhile. For example, research shows that our brain ‘disconnects’ after 10 minutes when nothing changes. In a training setting you would use this knowledge to change the setting regularly or to make short exercises or chunks of information. In a Scrum event you could use this knowledge also.
How? That’s what we will explore during this session.
In this session you will learn about neuroscience and how you can use it to activate your brain and make your Scrum Events alive and active. Bring your Brain!
Ask around and you’ll hear a level of adoption across industries and domains similar to the big wave of Agile adoption in the late 00’s into the 10’s. For a 40 year old goal-setting framework, OKRs are having quite an impact on the business world. There are increasingly more books on the topic, software to support OKR rollout and a rising number of consultants specialising strictly in their deployment across companies large and small.
In this talk Jeff will share what OKR’s are, how to write them effectively, why they’re powerful and what to look for as organizations begin to implement them.
What are the executives concerned about? And how can agile contribute to it?
Many times, in the agile world, we focus on efficiency or we focus on the ways and the techniques that can help us improve our way of working, in addition to putting some frameworks and practices in place.
However, for executives, that’s not what matters the most.
What they require is to address concrete problems and particular struggles that they face. And when they do that, they have to do it under a budget and a schedule.
Therefore, when they are tasked with something as abstract as changing the culture or the ways of working, it becomes imprecise, difficult to grasp and disconnected from tangible business outcomes.
So, the purpose of this talk is to share the most common concerns from executives and how to properly communicate with them by using their language. In other words, how to talk so that they want to listen.
See you there!
As we venture into the post-industrial age the delivery of ‘stuff’ becomes easier, but the delivery of value becomes harder. The Product Owner is a set of accountabilities defined in the Scrum Guide that provide the bare minimum things that someone needs to do to enable Scrum to work and value to be delivered. To manage the tension about work vs value. Of course, those accountabilities do not describe everything a person does, and many organizations use this as a foundation to create a Product Owner role or add those accountabilities to existing jobs such as Product Manager, or Business Manager. And that is where the confusion begins. The blending of the role and its position inside existing industrial-based organization structures. But what and who is the Product Owner? And why are their accountabilities so important for delivering value in an agile way?
In this talk, Dave West, CEO of Scrum.org and recovering Product Owner talks about what makes the Product Owner often the most misunderstood person in Scrum.
Agile Teams do benefit from member stability, but to which extent?
In this talk, Heidi Helfand, author of the acclaimed book Dynamic Reteaming, will discuss topics such as:
- What are the benefits and the risks of changing team members?
- Can you avoid that a team change its members?
- Can you use reteaming as a tool to increase people motivation, organizational resiliency and flexibility?
- What are the patterns of reteaming?
- Which practices enable reteaming? Which ones constraint it?
Do not miss it!
We all know what a product is. We buy and use them all the time. But, what does it mean where you work? Are the things you build or make really products or not? Are you creating a successful product, or just doing a job? We’ll talk about what product thinking really means and why you and your company may not actually be using it. And, if you’d like to be more product-centric, some specific principles for doing that.