If I Can DevOps, So Can You – Part VII : “You can put nearly anything in a pot and call it soup…”

When trying to wrap my own head around what I was going to need to actually implement a basic automated deployment pipeline with the kind of tools I felt that would be representative of a basic setup, I found myself awash in tons of blogs, articles, product pitches and “expert” advice. It felt daunting. 

However, I was determined to grasp these concepts, as my prior role at a Chief Technology Officer had me managing teams who were doing this all day, and I felt I lacked a tactile connection to the work and staff I was managing. The other reason for wanting to do this, was, in short, a strictly executive concern, that is understanding our resource consumption, spend and overall complexity of the systems we were building. It is exceptionally easy to fall into the trap of, if you have several projects that are running at once, to have each team independently making architecture and technology decisions in isolation, which can lead to duplication, and at worse, non-complementary choices.

To avoid some of this, and maybe bring in the first aspects of technology governance into the picture, is to utilize parts of Agile, what I like to call meta-scrums, or topic, rather than team-centric scums to ensure alignment on major aspects of your project portfolios. These differ from most potential team meetings as they are primarily updates, short discussions and decision actions. For my teams, our most important were our data and our architecture scums, the former bringing in some of our product owners who were not part of our technology team, but were from our data team under the Chief Data Officer.

Communication is key among intra-team coordination within your technology group, but also for others who are consumers or partners in the services and capabilities you are providing.It will reduce re-work, complexity, and better align resources in order to deliver feature complete and on schedule. This builds confidence among your constituents and will work as organic “public relations” to help build support for your work. But, as with most activities of this type, it’s important, vitally important, to manage expectations among your team, your partners and customers, and set realistic goals among everybody. 

Part of introducing a new way to do business, whether it’s reevaluating workflows and processes, to changing how technology solutions are developed and delivered is organizational change management. This is a critical function of these activities that are often glossed over, ignored, or dismissed out of hand (almost as much as human factors and user experience concerns, but that’s another article) and are done so at great risk for adverse outcomes. Many teams assume that, as resilient and adaptable humans are to change, the variety of characteristics of your organization and customers offer more variance than simple assumptions can capture. Change is complex, especially at scale, and not only needs technical change management but also the management and stewardship of introducing that change and ensuring its success to your customers and partners.

This comes to part of the soup metaphor. You can merely throw things in a pot with broth and call it soup, but to make a soup that has the right mix of flavors requires careful measurement, timing and selection of ingredients. Organizational change management involves careful planning, scheduling and the right people involved to carry the effort forward to success. There may be an ingredient that sours the pot, spoiling the soup, as there may be a member of your organization that, no matter how much this is massaged, integrated and communicated, will refuse or actively work against your efforts. It’s okay to anticipate this happening and have strategies developed to address some concerns and develop mitigations, but do not go in search of these cases, as they will tend to be edge cases, and strategizing results may involve more time, effort and resources than could be better used elsewhere.

Once you’ve integrated this capability into your application development and technology service delivery strategy, the smoother your current and subsequent activities will be. It’s somewhat Pavlovian, that with the right stimulus, you can condition your organization to handle change – both large and small – and ease prior heartburn derived from “big bang” deliveries that didn’t consider the organization’s needs, desires, current culture and methods of creating and completing work. This type of work is perfect for Agile as a methodology, as small “wins” for change will still have a significant impact and the “bite sized” nature of issues identified and addressed allow for easier course correction.

Of course, measuring success is not always going to be a straight quantitative measure, as uptake, adoption and satisfaction is more qualitative. However, ensuring your measures have elements of both quantitative and qualitative selected metrics will assist in divining whether or not your actions during these changes were resulting in the expected outcomes. Developing complimentary questions to measure the sentiment or feel of a straight qualitative metric of a rote number. While you may have hit 95%+ of target systems or services upgraded, did your organization see an impact to their work output, quality and effectiveness? These are part of the considerations when planning for organizational change, strikingly similar to the same discussions that should take place during technical change management meetings.

Taste your soup, get a read on the melding of flavors, add a little salt or pepper, or something a little more exotic, but always sample to see how close it is to your planned goal. This goes the same for change in your organization, get the sentiment and feedback and integrate that where possible as user stories, backlog items, or even major future enablements. If you don’t you’ll end up with something inedible and a huge pot of something that was a waste of time and resources that you’re left wondering what to do and with folks questioning your abilities.

Now, I’m in the mood for some chili.