Your work is going swell and everyone seems to be happy. But are things going as well as they could be? What frustrations are people experiencing but not verbalizing? Does anyone think that things should be better?

Maybe your backlog keeps slowly growing or it's a struggle to meet sprint commitments. Is your team taking longer to onboard new team members? Are there quality issues in deliverables? Team turnover increasing? Maybe you just feel like things aren't as simple as they used to be. Perhaps it's time to look at your team structure and how you organize around the work you deliver.

Join me for a peek at what might be a canary-in-the-mine signal that it's time to consider splitting the team and how to work through the decision. We'll look at the risks/rewards you'll likely face. We'll explore some potential dimensions to consider when undertaking a split. I'll give you some things to consider preparing for the breakup, how to minimize the downsides and how to navigate through the process.

Agile is all around us. We see agile in small and large software teams. We see groups holding standups, using Kanban boards, and conducting retrospectives. IT and business teams are asked to do more with less and get it done quicker…and agile is the answer to all of that. Is it really the silver bullet? Will we get to our goals if we adopt agile practices? Do we know if we're doing things in a way that will help us?

An agile implementation based on incomplete or erroneous information may be creating as many issues as it solves. We may be doing twice the work to "transform" to agile without seeing any tangible benefits. In the end, we fail in our goals and we're ready to go back to what we know best.

But what if it isn't that hard? What if we just need a bit of core knowledge, a chance to practice, and a safe environment where we can ask the questions that will move the needle?

The team leading this workshop organizes Lincoln's agileLNK Meetup group (https://www.meetup.com/agileLNK/). At this workshop, we will demonstrate several agile techniques, explain when to use them (and when not to), and discuss the foundational agile principals behind each one. Every team uses standup meetings, right? What if not everyone is in the same time zone…or hemisphere? You will learn how to use familiar agile activities, but also why to use them and what alternatives fit better in different situations.

Common agile topics we will cover during the session: * Sprints/iterations * Standups * Backlogs * Retrospectives * Metrics * Self-organizing teams * Kanban * Scrum

We will have plenty of informal interaction time as well. Have a tough question or need advice? No problem. We're here to help!

The Agile Ball Point Game is a fun and exciting way for development teams to explore process flow and gain insights into team interactions. Over the last year, I have administered the Agile Ball Point Game with elementary children, high school young adults and professional adults. Watching and observing these interactions has provided valuable insights in how teams interact, how teams should be structured and what works on teams.

This session will explore and introduce the Agile Ball Point Game, followed by an analysis of what was learned from playing this game with others. Topics will include the significance of suggestion, the value of diverse team composition and the importance of unconventional thinking on teams. The value of micro-optimization will be explored.

Additionally, the concepts of agile gaming will be introduced and expanded on.

https://drive.google.com/file/d/1mUL65QmYmvHFO7VYfNauF43Q9eyFM85j/view?usp=sharing

https://drive.google.com/file/d/1RKgJgbNUTblPceEuLFKrb8cVYWvivvZH/view?usp=sharing

Pair Programming is a highly recommended but seldom utilized agile development practice. Primarily originating and associated with Extreme Programming, Pair Programming is often misunderstood and therefore left by the way side when agile teams get going with development. I want to go back to the basics of pair programming and show why it should be a practice every team employs. In Design Studio and Senior Design, we managed nearly 40 projects with more than 200 student team members combined. Pair Programming can greatly impact these students’ careers in software development once they have realized its power and taken advantage of its benefits. Let’s bring it back down to the basics to remind you of this great opportunity.

You've decided Machine Learning (ML) can help your customers? Great! But ML can be difficult, time consuming, and expensive. Agile practices can reduce these costs and improve outcomes in the same way they've always helped: by making sure we're building the right thing every step of the way.

We've identified, and our presentation will speak to, the following anti-patterns for machine learning and agile approaches that avoid these anti-patterns. We value: * Iterative over incremental * Always be releasable over "toss it over the wall" at the end * ML as a means over ML as the end goal

For each anti-pattern, we will present several techniques to mitigate it.

Avoiding Incremental Development In Favor Of Iteration * Find 'minimal learnable concept' and get a complete ML pipeline quickly * Improve your ML pipeline from data preparation to deployment, don't waterfall it * Realize when something isn't feasible early on to avoid wasted effort

Integrate ML In The Product From The Start, Not At The End * Avoid answering the wrong question by focusing on outcomes and stories * Prevent overwork by only doing what's needed to get the desired result * Experts may identify easier-to-solve adjacent problems that have comparable outcomes for users

ML is a feature like any other - it is a means, not an end * Identify when it is not the right tool for the job * Know when good enough is good enough * ML stories should be prioritized, have story points, etc.

Everyone has heard the old adage "measure twice, cut once" yet it can be so difficult to get a team to adopt this mentality when it comes to writing code (cough cough... unit tests...). Software may not be quite as tangible as a bridge or an airplane, therefore it can be easy to dismiss the fields of structural/mechanical and software engineering as having little to nothing in common. However, many of the foundations of Agile stem from the manufacturing industry, and the co-creator of Scrum Jeff Sutherland writes of how applying Scrum to a construction project can greatly reduce the overall project time and improve quality. In reality, all of these fields are about buidling, maintaining and improving things and thus they have a lot more in common than you would expect.

During this presentation I'll share some of the lessons that I learned growing up building houses, and high-performance race cars with a father who is a bit of a perfectionist and we'll explore how many of those lessons can help improve how we approach software development. We'll also briefly discuss why some other industries could gain a lot from adopting some common software practices.

A curious observation occurred during sprints. My Product Owner (and good friend) would be rushing off to meeting or constantly stressing about work that wasn’t planned. Our Tech Lead (and good friend) and I concluded, he had a Secret Backlog in addition to the team’s Product Backlog.

A Secret Backlog is composed of the things that are desperately important to an individual, but the team or leadership cannot be influenced to work on them. These backlog items have real consequences and strict due dates. They can have significant financial impact if not executed properly or prudently. On the surface these projects require a specific skill set usually only found in the owner. Accordingly, the owner enjoys doing this work making the habit self-reinforcing and addictive.

This presentation hopes to provide clues about Secret Backlogs, allow space for participants to discover them in their companies, and provide the skills to help remediate.