Software projects often mistake organizational problems for technical issues and treat the symptoms instead of the root cause. The main reason is that the organization that builds the system is invisible in our code. From code alone, we cannot tell if a module is a productivity bottleneck for five different teams, or whether our microservice boundaries support the way our codebase evolves or not. This session closes that gap by taking a behavioral view of code combined with insights from social psychology to measure aspects of software development that we haven't been able to capture before. You learn how this information lets you detect modules with excess coordination needs, measure how well your architecture supports your organization, as well as why Conway's law is an oversimplification. To make it specific, each point is illustrated with a case study from a real-world codebase.

The technical debt metaphor has taken the software world with storm. No wonder, since software projects have their fair share of challenges. Most organizations find it hard to prioritize and repay their technical debt. The main reason is due to the scale of modern systems with million lines of code and multiple development teams; No one has a holistic overview. So what if we could mine the collective intelligence of all contributing programmers and start to make decisions based on data from how the organization actually works with the code? This session introduces one such approach with the potential to change how we view software systems.

In this session, you'll get an introduction to techniques that help us uncover both problematic code as well as the social dimension of the teams that build your software. The techniques are based on software evolution and findings from various fields within psychology. This combination lets you prioritize the parts of your system that benefit the most from improvements, detect organizational issues and make practical decisions guided by data. Each point is illustrated with a case study from a real-world codebase.

Too often innovative people in medium to large organizations have the feeling of being in a box - with startling new ideas - and no one really listens. In essence, these innovators are trying to “measure performance upwards.” This upward voice intrinsically measures strategies and customer impact, and applying the concept can significantly improve the overall performance without relying on top down OKRs and KPIs. Moreover, “measuring from above,” tends to measure the output of production rather than the truly important outcome: what is really making a difference for our customers and therefore for our company.

Adding “measurement from below” to a company can create a mindset that empowers everyone to follow their passion and interest and nourish the company’s effectiveness. Implementing a “from below” approach to measurement involves a fundamental shift that asks the company to synthesize a variety of new approaches. One such synthesis is Beyond Budgeting, Open Space, Sociocracy, and Agile (BOSSA nova). This synthesis enables a company to “measure upwards” without jeopardizing the strengths of “leading downwards.” Fortunately, the implementation can be done in small steps that probe and demonstrate new measurement ideas on a small scale such that the proof cascades beyond the demonstration. This session will enable you to get started on your journey to spreading the idea of upwards measurement company-wide.

This workshop asks participants to start where they are, explains what it means to probe, and helps them develop strategies and experiments they can use in their own situation to create an environment for high performance that goes beyond what OKRs and KPIs can offer.

This product thinking, leadership, and process workshop combines contemporary tech product thinking with agile development and Scrum.

Stop! Don’t bother taking this course if your only concern is learning Scrum and mastering the product ownership role. Because:

This is not just a product ownership class

This online workshop is about product thinking and how to apply it in your organization.

Imagine you are a Mad Agile Scientist and have a diabolical experiment to conduct - what would happen if you exchanged the brains of a Product Owner and Scrum Master? Mwuhahahaha!!! How would the body of a Product Owner with the brain of a Scrum Master act? And vice versa?

Perhaps the Scrum Master would now treat the team like a backlog? This Scrum Master would be focused on value and maintaining a coaching backlog of team and person improvements. This Scrum Master is refining the team, crafting a group that delivers value.

And perhaps the Product Owner might treat the backlog like a team? Rather than backlog refining, they coach the backlog. They would be focused on nurturing, protecting, and empowering the backlog. The backlog might transform from an irritation into a labor of love.

Although this experiment sounds terrible, this change of perspective might be what you need to reanimate your dead team or backlog.

Join the fun and come learn what horrifying results await!

Are you "doing it" the TDD way? Really? Are you getting the results from TDD as you expected? Yes? Great, check out one of the other exciting sessions at this conference.

No? Then: How come? Isn't TDD supposed to be easy? Just do the red-green-refactor dance and all code's gonna be functional plus clean.

Sorry, but I beg to differ. It's not that simple. And there are many reasons for that as I'll show you in this talk.

My main objection is, that TDD as it's commonly explained and demoed, is ignoring the plain and simple reality of problems being of very, very different difficulty. Or have you ever seen a TDD demo beyond the usual code kata exercises like "Fizz Buzz" or "Game of Life"?

Hence in this talk I want to present a bigger picture. I'll classify programming situations according to the Cynefin framework and put TDD in perspective. It will become clear where TDD might be a good fit and why - but also, where TDD is overtaxed.

And since TDD is only a fit for a small subset of problems, of course alternative approaches to test-first programming will be presented.