Agile development often focuses on immediate concerns: what am I doing now, or, at most, in this sprint? Even in situations where developement is Agile, architecture is often… not.

Ahead of the Pack is an approach to architecture running only one or two steps ahead of development, with the same level of focus: what feature am I describing for the developers right now? Ahead of the Pack means descibing objects—or database tables, or other discrete entities—in terms of their relationship with what has already been developed, so that updates to the architecture do not fundamentally modify what has already been built—or what has already passed quality assurance.

We draw examples from real applications, and provide a glimpse of future directions.

Everyone is doing it....using scrum that is. In this workshop, we will walk through the do's and do not's of this popular methodology. Using real life examples and years of expierence to draw from, presentor Rob Versaw will help you understand what has worked for him and teams he has been on throughout his career. Come with questions and ready for a hardy discussion!

User Experience (UX) focuses on people and their interactions with the world. The UX Design process links research to the creation of the design and can be used to validate use cases and user requirements that are part of Agile development processes.

This workshop will give you an introduction to the research with people who will use a product. You will learn how it can be used to assess the efficiency, effectiveness, learnability, and error reduction of alternative designs.

Completing a sample project will allow you to experience some of the steps in the user centered design of a software product. You will use data to: • Understand who will use the product through the creation of a persona • Create and test design prototypes, and • Implement what has been learned in a draft of the final design.

“Simplicity—the art of maximizing the amount of work not done—is essential”.

This is perhaps the most difficult Agile principle to follow. My take on this principle is a new word… Enoughionism. It’s not really at the other end of the spectrum from perfectionism, but somewhere between it and disorder/insufficient. If you could find a definition in the Dictionary, it might be something like this:

Enoughionism (ee-NUF-uhn-ism) – The theory that for any given desired outcome there is a level of sufficient completion that satisfies the need without providing a perfect solution. Any effort past the sufficient level will result in diminished returns, wasted effort or features that aren’t needed. Great care must be taken to ensure that simple solutions are pursued.

This session will lead participants through a few simple steps to apply the principle of simplicity in both their personal lives as well as the work environment. We will learn how to determine desired outcomes, identify when enough has been done, and then focus on moving on.

Understanding the differences between Principles, Systems and Tools is critical to successful Lean and Agile transformations. Without the proper understanding practitioners are likely to use a hammer on a screw.

Principle - a statement of value or fact that can be applied to virtually every situation and is usually generic in nature Tool - a specific application of one or more principles in a way that produces a desired outcome. System - a complex application of multiple tools that all work together to provide a desired outcome. Changing or removing one of the tools may not cause the system to fail, but it may cause the system to not be as productive or effective.

Participants will gain a greater respect for the underlying principles behind Lean and Agile along with appropriate ways to use Systems and Tools to their best advantage.

This is not just another “Use Chef, Puppet, or Ansible” talk. Tools looking for problems can lead to bigger headaches than applying sound practice to your efforts. There will always be cases when using a pure configuration management solution like the ones above may not solve all problems. Sometimes faster delivery capabilities, lack of necessary features within a plugin, or work out of sync with development teams can lead to issues ranging from annoyance to production outage. Going from manually edited application configurations on a production server to a fully automated deployment and testing solution can take many paths. If you follow agile development efforts, you can start handling configurations in a “Crawl, Walk, Run, then Fly” phase. I’ll use Apache, Tomcat, and Puppet to create some examples of problems with editing configs right in prod, and move towards some solutions to test, build, and deploy configurations just like a software engineering deployment pipeline.

Maybe you think you're using Kanban now, but are you just tracking tasks in big ugly list? Kanban's focus on Flow, Work in Process, Visualization, and Continuous Improvement requires a change of mindset. With Kanban, teams must prioritize completion of work, maximize effort, and constantly increase efficiency. Where Kanban can provide the most value is in dealing with unplanned work, competing priorities, and unknown variables at project start. Examples of these types of projects include:

• Legacy projects migrating to a cloud platform
• Budgets shifting towards newer investments
• A new merger brings on new properties
• Existing projects have shifted into an end-of-life, but not end-of-support phase

Or maybe, you're a support desk, service desk, or an on-call workforce for production issues. Kanban allows teams to learn from the work completed and pivot out of the chaos of all urgent requests all the time.