Janelle Klein

The Art of Better

Wed 5:00 PM

What does “better” really mean? If we eliminate duplication, is the code better? If we decide to skip the unit tests, are we doing worse? How do we decide if one design is better than another design?

About 8 years ago, my project failed, despite “doing all the right things”, and shattered my faith in best practices. Since then, I’ve learned to measure developer experience, use data to learn what works, and I’ve been codifying “better” into patterns and decision principles for years. In this talk, I’ll show you the paradigm shift that led to all my discoveries, and hopefully change your perspective on “better”.

“Idea Flow” is an alternative to the Technical Debt metaphor that focuses on problems in human interaction rather than problems inside the code. By measuring the “friction” that occurs when developers interact with the code, we can identify the biggest causes of friction and systematically optimize developer experience.

Why go to all this trouble? From my experience, the biggest causes of pain are seldom what we think. When we try to make things “better”, we can easily miss our biggest problems, or inadvertently make things worse. Visibility turned my beliefs about “better” upside-down.

First, I’ll walk you through the conceptual metaphor of “Idea Flow” and how to recognize friction in developer experience.

Next, we’ll write a little code and record the experience using the open source “Idea Flow Mapping” software.

Finally, we’ll discuss a handful of “decision principles” for optimizing developer experience and analyze our coding experience as a group.

The Art of Better (Part 2)

Wed 8:00 PM

Digging one level deeper into the details of Idea Flow Learning Framework, we’ll do this second session as a group troubleshooting game! After we play the game, we’ll do an “Experience Review” and analyze the causes of diagnostic difficulty, the nature of decision-making, and discuss strategies for making better decisions.

The Troubleshooting Game: I’ll split the audience into two teams. Team 1 will stealthily hide a bug in the code. Team 2 will have to track down the bug in as little time as possible. Then Team 2 will have their chance to stump Team 1. The team that troubleshoots the bug the fastest will walk away with an exciting prize!

After we play the troubleshooting game, we’ll do an “Experience Review” with each team’s coding experience. Rather than optimizing the code, we’ll focus on optimizing the problem-solving process. We will:

1. Visualize and discuss the differences between code sandwiches
2. Identify the major factors that caused diagnostic difficulty
3. Discuss the troubleshooting strategies used by each team and what made them more or less effective.

While it’s certainly challenging to understand how we think and make decisions, it’s an incredible opportunity to learn. By recognizing the inputs to our decisions, and how we evaluate trade-offs, we can compare our internal decision-making logic with our peers. With objective feedback on the consequences of our decisions, we can systematically optimize developer experience.

Learn how to master the art of software development with Idea Flow Learning Framework!

Make a FOCOL Point!

Thu 8:00 PM

Have you ever wondered whether your retrospective format was actually effective at fueling learning and improvement? Are you ready to try something different?

“FOCOL Point” is Idea Flow Learning Framework’s “stop and think” protocol. It’s a reflection technique based on the scientific method, action learning, and the socratic method. It works just as well for team reflection, personal reflection, or mentorship. As opposed to searching for answers, the FOCOL Point method helps us find the right questions.

Once I walk through the protocol as a group, we’ll make a “FOCOL Point” as a group.

First, we’ll identify the biggest software problems faced by the audience using the “flashstorming” technique. Then we’ll focus on the top problems of the group and start digging into the details by walking through a group-adapted version of the stop and think protocol:

1. Focus: What’s the outcome we’re trying to understand?
2. Observe: What patterns do we see? (for all pattern types)
3. Conclude: What major factors seemed to cause the outcome?
4. Optimize: How could we have made better decisions?
5. Learn: What questions could we ask ourselves to recognize future risks?

Amplify your learning by reflecting more productively on your own or with your team! You can immediately apply this technique on your own projects.

Top 5 Reasons Why Improvement Efforts Fail

Fri 9:00 AM

This is my story of lessons learned on why improvement efforts fail… I had a great team. We were disciplined about best practices and spent tons of time on improvements. Then I watched my team slam into a brick wall. We brought down production three times in a row, then couldn’t ship again for a year.

Despite our best efforts with CI, unit testing, design reviews, and code reviews, we lost our ability to understand the system. We thought our problems were caused by technical debt building up in the code base, but we were wrong. We failed to improve, because we didn’t solve the right problems. Eventually, we turned our project around, but with a lot of tough lessons along the way.

To learn, we need a feedback loop. To improve, we need a feedback loop with a goal. There’s five different ways our project feedback loop can break:

• Broken Target – Our definition of “better” is broken.
• Broken Visibility – We don’t see the pain, so we take no action.
• Broken Clarity – We don’t understand what’s causing the pain.
• Broken Awareness – We don’t know how to avoid the pain.
• Broken Focus – We see the pain, but our attention is focused on something else.

Find out how to repair the broken feedback loops on your software project by learning from my mistakes.

Stop Getting Crushed By Business Pressure

Fri 10:45 AM

This is my story of lessons learned on how to stop the crushing effects of business pressure… I was team lead with full control of our green-field project. After a year, we had continuous delivery, a beautiful clean code base, and worked directly with our customers to design the features. Then our company split in two, we were moved under different management, and I watched my project get crushed.

As a consultant, I saw the same pattern of relentless business pressure everywhere, driving one project after another into the ground. I made it my mission to help the development teams solve this problem. This is my story of lessons learned on how to transform an organization from the bottom up. I’ll show you how to lead the way.

Warning: This strategy won’t work in all organizations. In some cases, management doesn’t want to know the truth. However, in most organizations I’ve worked with, management wants to improve, but doesn’t know how to fix the system.

The crushing business pressure is caused by a broken feedback loop that’s baked into the organization’s design. In this presentation, I’ll show you how to fix the broken feedback loop. Learn how to:

• Gather evidence of developer productivity loss
• Identify the key organizational changes required for success
• Make the case to management for improvement
• Partner with your manager for long-term success

If the system is broken, we need to fix the system. You can change the system by making the decision to lead.

Note: This talk is not strictly dependent on attending, “Top 5 Reasons Why Improvement Efforts Fail”, but you’ll get way more out of the session, if you attend both.