Example2

I will initialize the __init__ method of the Tk class with the built-in super() function

/ Flow, Lean, Agile / By

Developers should avoid jargon and learn how to speak a business-focused plain English with their business counterparts.

The problem

Sometimes I see developers trying to communicate with product owners using a strictly technical task-based jargon. That often translates in misunderstandings and frustration on both parts.That’s not a good result for the product owners, for the developer’s career, and for the organization they are working with neither.

That’s not limited to the Product Owner/Dev  communication, tough. Technologies are constantly emerging and communication can also be a problem within specialists  with different skillsets. You could be a strong Senior Java Dev, but you could easily have no clue about what I’m saying if I tell you: “I defined the CamelContext using custom XML syntax, but without the route definition” because you don’t know the Camel Framework.

But back to our Product Owner/Dev information flow. While Product Owners should have a clear understanding of the business implications of the technologies at the core of their products, developers and engineers should be able to clearly communicate  the reason of the tasks they are performing daily and the relative business impacts.

Devs usually need to present difficult activities performed on complex data and processes. Attention spans of Product Owners are shorter than ever, and the situation gets even worse with remote working. So, how can techies  translate their activities in short and concise plain english concepts?  While some devs are more incline than others  to communicate without jargons, what I suggest here is a simple  two steps process that can be adopted by anyone.

Here’s it.

  1. Know your Audiences. What’s  their attitudes, needs, and expectations. How technical are them? Are they impatients? In a hurry? Willing to get into details?  Based on the Audience you should decide for
    • A direct, deductive  approach where you push the key message (i.e. we must improve the quality of our code)  at the beginning and then you could optionally give supporting evidence to convince them that it’s important. If they trust you, that’s usually the best way;
    • An indirect, inductive approach. You start with the problem (i.e We can’t deploy the product on Nexus) and then you develop the steps for the solutions. That’s usually more appropriate in a technical environment, with a common shared culture and skillset.
  2. Have a clear key Message. When speaking to a business counterparts, always focus on business impacts (i.e. we can’t test the product) instead of technical aspects (i.e. it does not build the pipeline with Gradle)

So, let’s see a practical example, with fictional characters: Mark the junior developer, Jeff the product owner, and Marcello the client. I adapted the code from Tkinter GUI Application Development Cookbook, by Alejandro Rodas de Paz.

At the planning meeting

Let’s imagine we are at the backlog refinement meeting of a Scrum team. They have been using Scrum for over 12 months now. The new product owner Jeff has a strong marketing background, but weak technical skills. Stories are discussed from the backlog.

When it’s Mark turn, he starts to talk about a new “technical” story he would like to have on the backlog in order to reduce technical debt about  the “Ciao Marcello” app. Jeff, the Product Owner is confused: the functionality already exists and performs well: when you click on the “click me!” button, it prints out to the terminal a “Ciao Marcello” message, so that the client is happy.

So Jeff asked about the reason for the new story. Here’s Paul’s answer.

OK, the story on the “Ciao Marcello” button. I want to define a class to wrap all the global variables in the app, enclosing the variables in a specific scope. I also need to move the command function in a specific method and replace the wildcard import with the “import … as” syntax. Finally  I will define an App class as a Tk subclass,  referenced via the tk namespace. I’ll initialize the  __init__ method of the Tk class with the built-in super() function.

What’s wrong with that? Nothing, except that the business impact of Mark’s activities is missing, and the reason why he’s willing to employ his time, paid by the business, in these activities remains unknown.  The jargon is totally obscure to Jeff, and there is no clear message that could make sense to him, just a series of technical tasks. Jeff starts to suspect that Mark has a different agenda, not aligned with the business objectives.

So let’s break the message down, and let’s refactor it with a more plain-english business-oriented focus

Task orientedBusiness oriented
No overall objectiveI want to improve the quality of the app, maintaining the same functionality
1a. I want to define a class to wrap all the global variables1b. I will improve the quality and modularity.
1c. I tell you why I want to use local variables instead of global ones. Each variable adds a bit of complexity, but  global variables add complexity to the whole program, while local variables add complexity only in the portion of code where they are defined in. So maintenance of the app will be easier, and we’ll experience less errors  
2a. I want to enclose my variables in a specific scope. I also move the command function in a specific method2b. I want to avoid that future changes in the code  here will disrupt other modules and vice versa
3a. I want to replace the wildcard import with the “import … as” syntax3b. That’s a known best practice. I want to avoid errors caused by clashes with other modules/variables. That’s why I’ll change the import strategy
4a. I want to define an App class as a Tk subclass,  referenced via the tk namespace. I’ll initialize the  the __init__ method of the Tk class with the built-in super() function.4b. I want to easily reuse the functions I create

With the business focused explanations, business impacts are now much more evident. When Mark explained the story in business terms, he convinced Jeff to put the story in high priority on the backlog. Here’s the refactored app with all the best practices applied. Jeff also learned something new.

It is now a win-win situation, the app is a better one, the business value of the refactoring is clear and the Team communication has stepped up a bit. The story has been written with focus on the business impact, technical tasks added, and it has been closed in the first sprint available. Great Job!

So, I gave here a simple approach on how to structure technical arguments according to their business impact. The approach can be used by anyone. If you are unsure about your communication skills, prepare and rehearse your talk according to the audience/key message. It will improve your skills and your relationship with non-technical counterparts.

Marcello Del Bono is coaching and leading Agile Teams, supporting Transformation programs. He has multi-year experience as a Product Owner, Scrum Master and Agile Coach in e-commerce, IT, Marketing and Decision Support Systems in Media, Telco, Finance, Fashion industries.

Contact him on LinkedIn.

Example2

Inizializzo l’ __init__ method della classe Tk  con la funzione built-in super() 

/ Non categorizzato / By

Ingegneri e sviluppatori dovrebbero evitare il gergo tecnico task-oriented quando comunicano con il business. Dovrebbero invece sforzarsi di esprimere concetti anche complessi previlegiando sempre gli impatti sul business e sul cliente.

Il problema

Capita che gli sviluppatori, specie se con poca seniority, cerchino di comunicare con i product owner, i clienti, o in generale con il business utilizzando il gergo tecnico tipico del proprio dominio di expertise. Di solito il risultato della comunicazione tende ad essere se va bene mediocre, con frustrazione ed insoddisfazione per developer, business e cliente.

E non è solo un problema di flussi di comunicazione Business/Tech. Nuove tecnologie emergono costantemente e la comunicazione “tecnica” può risultare incomprensibile anche tra specialisti con skillset differenti. Ad esempio potresti essere un Java Dev Senior, e magari ti risulta incomprensibile se dico “Ho definito il CamelContext usando la sintassi XML custom, ma senza la definizione delle route” perchè non conosci Camel, che pure è un framework Java.

Ma torniamo alla comunicazione Business/Dev. I product owner dovrebbero avere la comprensione delle implicazioni di business delle tecnologie utilizzate, i dev dovrebbero invece essere in grado di comunicare chiaramente le ragioni e i relativi impatti di business delle loro attività giornaliere.

Gli sviluppatori affrontano e devono comunicare task difficili, con dati e processi complessi. L’attention span delle persone del business è sempre più breve, e la situazione è peggiorata ulteriormente con il lavoro a distanza. Quindi, in che modo i tecnici possono tradurre le loro attività in concetti brevi e comprensibili? Alcuni sviluppatori sono più inclini di altri a comunicare, ma quello che suggerisco qui è un semplice processo in due passaggi che può essere adottato da chiunque.

Ecco l’approccio.

  1. Conosci la tua Audience. Quali sono le attitudini, i bisogni e le aspettative della tua audience? A seconda della persona con cui parli, la tua comunicazione deve essere focalizzata con:
    • Un approccio diretto e deduttivo con cui comunichi immediatamente l’impatto di business (ed esempio, miglioriamo l’esperienza d’acquisto). Se serve, maggiori dettagli possono essere dati in seguito. Se il Business ha fiducia nelle competenze tecniche del team, questo è l’appproccio migliore.
    • Un approccio indiretto e induttivo. Si parte descrivendo il problema dal punto di vista tecnico (Non riusciamo a deployare su Nexus) e poi si descrivono gli step della soluzione. Questo approccio è corretto in presenza di un’audience tecnica, che condivide lo stesso skillset, ma è più rischioso davanti ad un’audience business.
  2. Un messaggio chiaro, conciso e focalizzato. Se parli al business, focus sull’impatto per il business (es. non possiamo testare il prodotto) piuttosto che sul problema tecnico (es. non riusciamo a deployare con Gradle).

Vediamo un esempio pratico con protagonisti fittizi. Marco, junior developer, Gianni, product owner, e Marcello il cliente. Il codice è adattato da Tkinter GUI Application Development Cookbook, di Alejandro Rodas de Paz.

Il planning meeting

Immaginiamo di essere al backlog refinement meeting di uno Scrum Team. Gianni, il nuovo Product Owner, ha un forte background di marketing, ma comprensione limitata della tecnologia.

Marco chiede di poter mettere una nuova storia “tecnica” nel backlog per rivedere la funzionalità dell’app “Ciao Marcello”. Il Product Owner Gianni è confuso: l’app esiste già e funziona bene: cliccando sul bottone “click me!” viene stampato a video il messaggio “Ciao Marcello” e il cliente è soddisfatto

Gianni chiede quindi quale sia il razionale della nuova richiesta del team. Ecco la risposta di Marco.

OK, la storia che vorrei fare per l’app “Ciao Marcello”. Vorrei definire una classe per wrappare le variabili globali, includendole in uno scope specifico. Sposto anche anche la command in un metodo specifico, e rimpiazzo l’import star con la sintassi “import …as” . Poi definirò una classe App come subclasse della Tk, referenziata sul namespace tk. Inizializzerò il metodo __init__ della Tk con la funzione super()..

Cosa c’è di sbagliato nella descrizione di Marco? Nulla, tranne il fatto che manca totlamente l’impatto di business delle attivbità descritte. Non è quindi chiara la ragione per cui Gianni dovrebbe dare priorità a una storia di cui non vede il valore. Il modo in cui i task sono descritti dice poco o nulla al product owner, così come al cliente. Gianni comincia a pensare che Marco abbia una sua agenda non del tutto allineata con gli obiettivi di Business.

Proviamo quindi a riscrivere la risposta di marco in termini più business oriented.

Task orientedBusiness oriented
Non è stato comunicato il contenuto di business della storiaVoglio migliorare la qualità e la solidità dell’app, pur mantenendo le funzionalità esistenti.
1a. Vorrei definire una classe per wrappare le variabili globali, i1b. Miglioro la qualità e la modularità.
1c. Ti spiego il problema con le variabili globali. Ogni variabile aggiunge un poco di complessità, ma quelle globali l’aggiungono a tutta l’app, mentre quello locali aggiungono complessità solo dove vengono definite. Così la manutenzione sarà più semplice, e avremo meno errori.
2a. Includo le variabili globali in uno scope specifico. Sposto anche anche la command in un metodo specifico2b. Voglio evitare che cambiamenti futuri in una parte del codice creino problemi in altre parti del codice, e viceversa.
3a. rimpiazzo l’import star con la sintassi “import …as” . 3b. E’ una best practice per evitare errori per conflitti con altri moduli/funzioni
4a. Poi definirò una classe App come subclasse della Tk, referenziata sul namespace tk. Inizializzerò il metodo __init__ della Tk con la funzione super()4b. Voglio poter riutilizzare al meglio le funzioni che scrivo.

Gli impatti di business sono ora molto più chiari. Spiegando la storia in termini di valore, Marco ha convinto Gianni a dare priorità al refactoring della storia, che è stata poi affrontata nello sprint successivo. Nell’immagine il codice dell’app, rifattorizzato.

La comunicazione nel team è migliorata, il valore del’attività è chiaro, il cliente ha un’app di maggiore qualità. Ottimo lavoro!

Ho presentato qui un semplice approccio per strutturare argomenti tecniche. L’approccio può essere utilizzato anche da chi non sia sicuro delle proprie skill di comunicazione e porta in definitiva alla creazione di maggior valore per il cliente e per l’organizzazione.

Marcello is coaching and leading Agile Teams, supporting Transformation programs. He has multi-year experience as a Product Owner, Scrum Master and Agile Coach in e-commerce, IT, Marketing and Decision Support Systems in Media, Telco, Finance, Fashion industries.

Contact him on LinkedIn.