Howard is a software consultant and educator who specializes in Agile process and practices. He has a varied background spanning well over forty years in the industry, with extensive experience in commercial software, aerospace, and financial services. He has played many of the roles in the development arena, such as developer, analyst, team lead, architect, and project manager. He has applied the principles of Agile, Lean, and XP development in teams both large and small, in various environments. Howard has educated dozens of teams, and is a long-standing member of the ACM and IEEE.
Pivoting a Company Towards GitOps and Continuous Delivery - A Technical Practices Coach's Tale for the Misbegotten
This talk is an amalgam of observations, opinions, findings, and musings from a Agile Technical Practices Coach working for an organization that struggles as it fights to change from a more traditional 20th century IT organization that services contract promises into a 21st century product organization that excites and delights their segment and channels. Your narrator has had a long term relationship with this compony and has coached them on topics varying from adopting an Agile/Lean mindset, organizational staffing models, product strategy, coding and testing practices, architectural concerns, wedding and bar mitzvah advice, and now into the world of how to achieve Continuous Delivery of quality product.
One central theme is that there is that a coach must act holistically, taking into account that both customs, culture, philosophy, and practices all compete in the wicked problem of pivoting the organization into a more modern and “Agilely Fluent” organization. Specific topics will come from the following (and without regard for “terminology correctness”as judged by the Agility Police):
* Requirements gathering
* Development environment
* Development infrastructure
* Coding practices
* Testing practices
* Developing a learning organization
* Production infrastructure and workflow
Each topic will illustrate the problems faced by the organization (and the coach’s experience of how their woes fit into patterns of problems that the coach has seen elsewhere), the coach’s vision of what would be a good outcome, steps along the way, and illustrative reactions from the organization to the change. The overarching message is that you must coach the organization at where they are, who they are, and what they do, regardless of your preconceived thoughts of what you’d like them to be and do. In other words, as a coach while you might know that X is a great way to accomplish Y, you must accept that not everyone is ready to do X, is capable of doing X, or even sees that Y is a good thing! If this talk alleviates another coach’s or organization’s pain and anxiety adopting better ways of approaching work, then I will consider it a good use of our time.
Synchronous vs Asynchronous Digital Circuits as an Analogy to Organizational Dysfunction Applied to DevOps Practices
Digital circuits, including the ones that we use for modern day computers, rely on digital electronics. That just means that they work because of a particular voltage being present to mean a one and the lack of a voltage to mean a zero. Itâ€™s how we build circuits together to transform an input into an output, with all of the circuits and programs to run on those circuits (in a von Neumann computer) that makes computers useful. But when designing these circuits, one basic design question to answer is â€œshould I use a clock or not (synchronous vs asynchronous)?â€ While synchronous circuits are easier to design, asynchronous circuits have many advantages, such as high performance.
Let me mapping this concept onto organization dysfunction. As a coach, I can tell within 5 minutes of meeting a client how well the organization will do when attempting to become more Agile through reductions in Lean Wastes by adopting some Software Craftsmanship and DevOps practices and principles. How can I tell? Easy. I look at their calendaring tools. When I see a personâ€™s email box full of calendar requests and a calendar that resembles a paved driveway, I know immediately that we will have a lot of problems. On the other hand, when the corporate culture embraces true one-on-one collaboration, with few meetings, I know that weâ€™re going to get on together just fine.
As an organization if we want to make progress on work to be done, we have a choice to make. We can either be asynchronous by collaborating together and getting stuff done, or we can take the route that has be drummed into everyoneâ€™s head over the last 159 years: we can hold meetings. Unhappily, the more we rely on meetings as the primary way of making progress, the less we get done because of waiting and coordination wastes.
This talk will discuss the underlying analogy more in depth, apply it to organizations we are familiar with, and discuss the proper role for meetings in an organization. It will then turn its attention to how DevOps in general and virtualization/containerization in particular allows us to be more asynchronous as an organization, and therefore much quicker and less wasteful.