If I Can DevOps, So Can You – Part IV : “But what if I don’t like what I’m cooking…”

Often the mark of a good chef is at least eating, or tasting the food before they send it out to be eaten. It takes but a few episodes of (or catching some of the memes) of Gordon Ramsay reaming out a chef for serving something inedible to realize that you know what you are putting out the door for others to consume, and have tried it to at least know if it’s too sweet, salty, sour or just right.

As I noted in my prior post, to continue to use the analogies of a kitchen and cooking with the move towards technology modernization, cloud-computing, agile and DevSecOps, and having a sous-chef to help you execute these plans, that person would be a scrum master or a project manager, you also need some diners who will be brutally honest with you, but also let you know that if you set up a traditional gastropub, you probably aren’t going to do well serving sushi empanadas or alongside french fries and chicken tenders.

In this case, you’ll need one or more product owners, depending on the size and scope, and perhaps even a champion within a business unit to assist with organizational change management. These are the conduit to your customers and constituents, they are the diners and guests for the meal you are to serve up, so it’s good to know what they want and what they are willing to consume. You’re going to have the occasional “picky eater” who will not want to move to a new system or solution, particularly an individual who’s gotten used to all the “kludges” put in place to have the system support the business process.

Speaking of that business process, your champions and product owners should be initially discussing the flow of work, the inputs and expected outputs, devoid of talking about any technology. There’s often a tendency to initially speak in terms of systems they access or the application used, which frames the discussion of capabilities limited to what they had versus what they actually want. This is part of, if not, one of the first steps of organizational change management. This is also one of the most important steps in getting folks onto the “on ramp” for modernization activities and integration into new development practices, as it poses a new way to think about problems and challenges.

As you’re beginning these discussions, this may be the first time some folks have actually been asked to openly think broadly and brainstorm about a problem. It’s also important, as a rule for initial brainstorming, is to remove most limits to what may be possible, in short, discussions about resources, timelines, personalities, politics and other organizational specific bounds should excluded from the discussion if possible. This frees up some of the creative problem solving that is a central tenet of user-centric software engineering. You’ll stimulate better ideas and encourage participation, barring any strange group dynamics, of more people on your team.

This activity will essentially give you the rough idea of the “menu” of services and desires, hopefully prioritized, of your diners. It’s then up to you and your team, or crack cooks, to whip up some interesting plates for them to consume. But, like any good chef, be prepared for feedback. Users should be encouraged to be vocal but constructive, maybe not necessarily have the exact language to translate their desires into wants and needs, but part of a product champion and owner is to have some subject matter expertise or experience in the work or activity you are supporting. 

They will be your translator, but also aid in training the appropriate members on your development teams in the important aspects and context of the desired work, without those staff becoming actual subject matter experts in the work. The benefit for your customer/constituents and your developers is that they shouldn’t have to role-play as those end users, which often times, when requirements are passed to them without context, would have to role-play where there are gaps in knowledge. This often, most commonly, can be seen as a poorly executed user interface or experience, where guesses were made and not verified early or often enough with those individuals. 

Your goal is generally to have happy customers, this is one step forward towards making them partners and supporters of your activities. This will also make justifying investment in further work a lot easier, given that the justifications, outreach and general socialization, if a good solution is delivered, is shared among your teams and theirs.