“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.