Database-Last Design

Many years ago, the database was used as the logical core of an application. It was essentially the domain model as well as all the business logic constraints. Front ends were usually designed to be prettier interfaces to database tables - the grid with action buttons at the end. It was common to design the database first before doing any of the code or prototyping.

Advances in UI/UX principles, software architecture, and available technologies have moved application development away from this paradigm and toward one that uses the database as cold persistence storage. Apps are now designed with the work the user must complete as the main focal point without regard to how this data will end up in storage.

This also has big ramifications for how agile and cross-functional teams develop software as we embrace technologies and patterns that are even more loosely coupled and free us to develop each piece to do what it does best.

What you'll learn:
- How did we get here? The transition from a database-centered business world to a function-centered business world
- How does this work? Designing software from the standpoint of the work rather than the storage
- How can this happen? Architectures like CQRS, actor models, functional programming, and microservices as well as technology choices like caches and NoSql models enabling agile, incremental software development that is user-focused

Life After Story Points: Planning without Relative Sizing

If you ask people what they like best about agile software development, nobody would say, "Sprint planning! I love having a hour long discussion over whether a story is a 3 or a 5!"

Sometimes, these difficulties come down to misunderstandings around relative sizing that can be easily corrected. However, there are ways of planning upcoming work and timelines that don't rely on any sort of sizing debates at all - relative or otherwise.

We'll take a look at a different way of measuring and projecting out work increments and timelines. If you are responsible for providing estimates and timeline expectations but have struggled with using story points or relative sizing to get there, these methods may work for you.

You'll learn:
- How to do planning around relative sizing correctly (if you're going to do it, do it well)
- What to measure to get actual data that doesn't rely on guessing
- How to use that data for planning, and how it can easily be misused
- Situations where one paradigm might work better than the other

Agile Requirements: Getting What You Need When You Need It

Prior to agile development, requirements gathering was a long, exhaustive process designed to produce a comprehensive document with all the details in it. Changes to this document usually required a big process. With few exceptions, this approach did not fit the changing needs of modern business.

When agile development came on the scene, documentation was often seen to be the enemy and development was engaged with little to no planning or understanding of what was being developed.

Now, many organizations struggle between these two polarities. How do you engage with requirements ahead of time to make sure you build the right thing while still allowing for quick responsiveness to changing business needs?

In this session, we'll look at principles and practices around gathering requirements that work them into an incremental, flow-based delivery practice.

You'll learn:
- The role of a high-level feature list
- A simple, acronym-free guide to writing user stories
- Acceptance criteria for capturing details
- How to balance keeping the development queue stocked with the risk incurred by premature analysis
- The value of capturing conversations
- What to do with all this stuff when you're done with it

Having Daily Standups People Actually Care About

Teams beginning an agile journey often implement a daily standup. Sometimes, the daily standup becomes a low-value ritual and attendance is a struggle as team members come to view it as an interruption that isn't worth their time.

Some try to fight this by jazzing up the standup in some way to make it more enjoyable, but it's often the case that you can remove things from your standup and tweak your team's workflow to create standups that are shorter while having increased value for the attendees.

In this session, you'll learn:

- The goals and core benefits of a standup that dictate what you should leave in and what you can scrap
- The goals for standups that greatly hinder effectiveness
- Who the right people are to have in a standup and when you should split into multiple standups
- The one key metric that simplifies most standups
- The role "swarming" plays in the effectiveness of your standups
- Standup format matters! We'll look at how the "traditional" format can unintentionally add time and lower value

This session requires no technical knowledge and is well suited to team members who either participate in some form of daily team standup and/or are responsible for facilitating them (e.g. Scrum Masters).

Great Retrospectives that Work

Virtually all agile efforts in software development incorporate some form of retrospective activity. For organizations new to the practice, they can easily become lengthy, unfocused affairs that fail to deliver on the promise of continuous improvement.

When retrospectves seem to have little value, produce no lasting change, or just create long lists of unrelated work for people to do, they tend to get minimized or cut altogether when time gets tight - the very time when retrospectives are needed the most.

In this session, we'll look at how to optimize your retrospectives to produce actionable, quantifiable results in less time.

What you'll learn:
- The goals/benefits of retrospective efforts that shape what you keep in and what you can get rid of
- The key difference between team self-improvement and individual venting
- Format matters - why the "traditional" retrospective structure almost assures that you will spend a lot of time accomplishing less than you wanted
- Measuring results - is there a way to know your improvement is "working" besides gut feel?

Scrum vs. Kanban: Yes, This Again

If you find yourself in an awkward social situation at a conference, ask aloud, "Hey, is Scrum better than Kanban?" and duck out of the room in the ensuing chaos.

Strong opinions exist on both sides of this fence, and as the data comes in, we've come to see that agile teams all over the world have been successful with either.

However, the fact that successful teams on both sides exist doesn't help you decide which is right for -your- team, and the patterns are not interchangeable. As SAFe and other scaling paradigms become more popular, even individual teams within the same organization may operate best using different structures.

In this session, we'll look at Scrum and Kanban, not to prove that one is better, but to point out how they tackle problems in different ways using different assumptions about the workflow. By seeing which more accurately fits your work, it may help you decide which to try.

You'll learn:
- Misconceptions about both sides that only prove marketing is evil
- How Scrum and Kanban make work visible
- How Scrum and Kanban deal with planning and projecting timelines
- How Scrum and Kanban deal with limiting work in progress
- How Scrum and Kanban deal with changing priorities
- Stuff Scrum deals with that Kanban does not
- Common crossover practices
- Workflow characteristics that may fit one scheme better than another

This session requires no technical knowledge and is well suited for people contributing to the decision of what workflows their team will use.

Hunting Down the Elusive MVP

Have either of these two things happened to you:
1. You invested a ton of time and money into a product that didn't do well in the market.
2. You invested a ton of time and money into a product for your own business that nobody used or got scrapped.

If this has never happened to you, great! It's happened to about eighty bajillion people, though, and organizations are starting to look at the concept of an MVP.

But there are so many ideas about what an MVP even is, much less how to get there. Companies find the process of defining and building an MVP just as cumbersome and clunky as developing a full product, and the end result is less than satisfactory.

In this session, you'll be exposed to some best-of-breed practices to help you end up with a defined, quantifiable MVP that's actually an MVP.

You'll learn things like:
- Visioning
- Personae
- User Journeys
- Story Mapping
- Evaluating Risk
- Creating a Sane Release Plan
- Identifying your MVP
- Creating a Canvas that Brings Everything Together

Product ideation is a struggle in today's market; perhaps you could be your company's expert in it.

Love Will Hold Us Together

Let's face it - it's easy to look around at our world and our country and get depressed. Although many quality of life metrics are on the rise, we still see a constant onslaught of stories that show us that humanity is still plagued with hatred, broken relationships, distrust, and hostility.

People often relegate the fight against this darkness to individuals or faith groups or perhaps certain non-profits, but have you ever considered how your company could actually be an agent in healing broken relationships, spreading joy, and changing people's lives for the better?

Integrity Inspired chose love as their top, core value, and in doing so, discovered that this expressed itself in a variety of software development, project management, and business practices that turn the dehumanizing dynamic of most systems on its head.

In this session, you'll learn:
- What love means in a business organizational sense
- What agile practices flow from loving your clients
- What agile practices flow from loving your employees
- How agility can help transform lives of people outside your company

The Power of Visioning

As organizations have gotten leaner in practice, some of the typical corporate standards like "vision statements" have fallen by the wayside, and for good reason - they often have little value or impact on what actually happens in an organization.

But maybe we've also lost the kernel of what could be good and right in crafting a common vision. Perhaps the problem isn't with having a vision; perhaps the problem is that our visions didn't truly help us grasp where our company/project/team/family vacation was really going. Perhaps they didn't inspire and compel. Perhaps they didn't help us make decisions. Perhaps they didn't help people decide if they wanted to be on the bus or get off at the next stop.

Visions, properly done, can provide all those things and more. They can be a power tool both personally and professionally, addressing scales as large as an organization's trajectory over the next ten years to as small as your PTO's bake sale. Or your teenager's college experience. Or what your own life could look like on your next birthday.

In this session, we'll look at visioning techniques pioneered by the crazily successful Zingerman's businesses and show you the following:

- What a vision is and isn't
- How visions can shape everything
- What makes for a practical and compelling vision
- Techniques for writing a vision, even if you're a terrible writer or have no idea what your vision might contain
- How to get feedback on a corporate vision

Optimize Your Dev Team with Fewer Fatalities

At some point in a team's agile journey, you start looking at improvement, perhaps through the lens of a retrospective.

It's very common for teams to adopt a shotgun approach to this, trying to improve everything everywhere. This often leads to even more disasters such as: trying to adjust to an unreasonable rate of change, not seeing any improvement, or starting Scrum.

There's no need to experience that bloodbath, though. This session is all about how to make the changes that matter most in a way that everyone can get behind.

In this session, you'll learn:

- Why "standard" retrospective formats are almost guaranteed to make meaningful change difficult
- Which metrics and visualizations actually matter when it comes to improvements
- The two, single factors that have the biggest impact on your delivery time (and you have control over both)
- How to use the Theory of Constraints (TOC) to make sure your improvements will matter most

This session requires no technical knowledge and will be of most value to dev team members and the people most in touch with their workflow (e.g. project managers, Scrum Masters, etc.).