Friday, September 13, 2013

Cynefin - Making sense of complexity



In my trainings, I’ve been using the Cynfin framework which was developed by Dave Snowden in 1999 while he was working for IBM, for a long time.
It really helps to describe the significant distinction between ordered and unorded - when a defined process works and when to use an empirical approach i.e Scrum.


So, I’ve been looking forward to listen to Dave Snowden first hand at the 5th LAS (Lean Agile Scrum) conference in Zürich last week.

Snowden is a great speaker with lots of insights and british humor. However, each sentence counts and it is loaded with information and very technical terms. As of know I am still digesting his talk.

For exactly that reason, I decided to summarize my take aways and share it for you and myself:

If you don’t understand you cannot adapt - If it works just keep doing it; however what to do if it stops working. Then you are out of your depth and since you did not understand it in the first instance you cannot effectively cope with it

Cookbook - Everyone can cook with a cookbook given the right kitchen with the right tools and all ingredients are available. However, if you lack tools or ingredients you need a ‘chef’ someone who understand the theory and knows the practice. By that time the cookbook is useless to the novice.

Consciousness is a distributed function - the brain, nervous system, hormonal system, … all have an impact in how we work. Consciousness is what a knowledge worker works with.

Body of Knowledge - BoK requires theory and practice. You need the theory and 2-3 years of practice (nervous system) to acquire the skills. Apprenticeship and serving time is key. Theory and practice combined are called praxis. Praxis makes perfect.

Exaptation - using something for something else - far more successful then adaption. Exaptation requires granular elements for recombination. Adaption causes slow change; exaptation is a far more successful strategy for innovation.

Architecture in Software - needs to allow for exaptation. Fairly fine grained objects, good scaffolding allow for free interaction and combination. Software development is a service based provision.

Taking a linear process and drawing it as a circle doesn’t make it non-linear (ditto not faster) - Scrum-er-Fall

Coherence - not perfect data but usable, semantically meaningful. Often we have to make decisions on data which is coherent but not absolute.

People make decisions based on ingrained patterns on past experience - whatever data available, it will be filtered by past experiences.

Complex Adaptive Systems (CAS) cannot be eliminated - we have to manage the non-linear causal dependencies and resulting turbulence in unordered systems.

Meaning exists between the gaps of people, not the people themselves - it is the interaction what counts, the relationship between is more important then the things themselves. Don’t change the person, change the way they interact. Manage networks, the vague gaps between things

Agents are anything that reacts within/withon a system - people, ideas, groups, myth

In the Simple domain - agents are fully controlled
In the Chaos domain - no constraints on the agents, wisdom of the crowds; chaotic system have value but they are complicated to create 
In the Complex domain - beneficial coherence through boundary management and attractors. We manage the emergence. (Emergence requires less resources then other processes). You can only understand it while interacting with it.

The Simple domain is adjacent to the Chaos domain - If an unordered problem is approached in a Simple fashion it  will transition straight to Chaos through an catastrophic event.

We like order, like to conform

The more bureaucracy the more informal networks in an enterprise

Hindsight doesn’t lead to foresight

Stupidity and Intelligence with Deception are the same thing.

Thursday, September 12, 2013

Palestra Jogos de trabalho no PMI-RS 2013 por @jorge_audy e @paulocaroli




O blog do Jorge Audy tem bastante coisa sobre o assunto. Recomendo!

Aqui seguem alguns links para referencia:

Jogos de trabalho - melhorando a eficácia do time de forma descontraída e animada



Venha participar de uma palestra que nos desafia a entender as motivações humanas, as mesmas para a vida e no trabalho. Dois séculos após a revolução industrial definir um novo modelo mental com foco em produção, experimentamos nas últimas décadas uma nova revolução, não de método, mas de filosofia, na busca por uma relação mais humana, em que cabe a todos, mas em especial aos gestores, o entendimento de que investir na pessoa começa pelo interpessoal, pelo lúdico, com transparência, confiança, senso de equipe, e muita brincadeira! Um grupo de pessoas não se transforma em um time da noite para o dia. Nesta animada palestra, você vai presenciar vários jogos para formação e evolução de um time de sucesso. Um time é um grupo de pessoas voltadas para um objetivo comum, onde cada indivíduo ajusta suas ações, hábitos e preferências de trabalho para alcançar o objetivo comum do grupo. A eficácia do time depende da capacidade dos membros da equipe para trabalhar em conjunto e está diretamente relacionada com a capacidade do grupo para fazer o melhor uso das capacidades dos indivíduos.

Jorge Horácio Audy
Coordenador e Scrum Master na área de desenvolvimento de produtos digitais do Grupo RBS na unidade do TecnoPUC de 2009 a 2013, da equipe de coordenação do Grupo de Usuários de Métodos Ágeis da SUCESU-RS desde 2012, Escotista desde 2005 no Grupo Escoteiro Guia Lopes, mestrando de 2013/1 no programa PPGAd da FACE na PUCRS. Mais informações sobre o especialista através de seu blog sobre métodos ágeis em http://jorgekotickaudy.wordpress.com, Twitter @jorge_audy, e LinkedIn em http://br.linkedin.com/pub/jorge-audy/2/b66/729

Paulo Caroli
M.S. em Engenharia de Software pela PUC-Rio, Agile Coach e Delivery Manager da ThoughtWorks Brasil, Paulo Caroli possui duas décadas de experiência em desenvolvimento de software com passagem em várias corporações no Brasil, Índia e EUA. Desde 2000, Caroli tem focado sua experiência em processos e práticas de Gestão e Desenvolvimento Ágil usando XP, Scrum, Kanban e outros. É sempre palestrante convidado em vários eventos grandes no Brasil e no exterior e também autor de diversos artigos. Foi o idealizador e um dos criadores, além de ser palestrante desde 2009 do Agile Brazil, um dos maiores eventos de desenvolvimento de software da América Latina.


Monday, September 9, 2013

One Week Inception - presentation



Below is the one week inception presentation that Taina Caetano and I (Paulo Caroli) have delivering on a few events, including the AgileBrazil 2013.

The coolest thing about this presentation: it is a sequence of photos taken on real Inceptions.


Monday, September 2, 2013

User Stories and Business Hypothesis



As I find myself diving deeper into the Lean Start up and the Lean Analytics world, I start questioning some of the Agile practices that been  have followed me on every single Agile project I worked on. For instance: the User Story.


As a < type of user >,

I want < some goal >

so that < some reason >.


This User Story format was created by Mike Cohn years ago [Users Stories Applied], and ever since it has used by many Agile teams. Typically, a Product Backlog has a list of User Stories to be worked on.

Nevertheless there is another kind of work which Lean enthusiastic are bringing to everyone’s attention:  hypothesis.


Hypothesis is a supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation.


I have learned the following representation from Alison Vale and Rodrigode Toledo.




Basically I was seeking a better template for a hypothesis. The User Story format was not working for this one. I need a good format to describe the ?, the -> and the ! – my hypothesis, the work needed in order to get this hypothesis in play, and the way to validate the results.


So here is my recommendation for a simple and generic hypothesis format:


If < I do this > then < this will happen >


I am currently calling these Business Hypothesis (please share if you have a better name for it). It includes the ?, the -> and the !; being the ? and the ! explicitly on the text, and  the -> should be handled as details for that hypothesis. This is similarly to User Stories, where the implementation details are not contemplated on the format as a… I want to… so that…

This has been working well for the teams I worked with. Please share your experience with hypothesis. Has this or other formats worked well for you?